threads / discuss / 22615

Separate default push/pull?

Subject: Separate default push/pull?

## tl;dr

8 messages between Feb 11, 2010 and Feb 13, 2010.

replies: 7people: 4as markdown or json

David Abrahams· Feb 11, 2010, 16:36 UTC · lore

If I am collaborating mostly with one other person, I typically want to pull from his publicly-readable repo and push to mine (on which I have write permission). Is there any way to set things up so “git pull” and “git push” without additional arguments will do this by default?

Thanks,
-- 
Dave Abrahams           Meet me at BoostCon: http://www.boostcon.com
BoostPro Computing
http://www.boostpro.com
Chris Packham· Feb 11, 2010, 18:57 UTC · re: David Abrahams · lore

Re: Separate default push/pull?

On Thu, Feb 11, 2010 at 11:36 AM, David Abrahams <dave@boostpro.com> wrote:
Show 18 quoted lines
>
> If I am collaborating mostly with one other person, I typically want to
> pull from his publicly-readable repo and push to mine (on which I have
> write permission).  Is there any way to set things up so “git pull” and
> “git push” without additional arguments will do this by default?
>
> Thanks,
>
> --
> Dave Abrahams           Meet me at BoostCon: http://www.boostcon.com
> BoostPro Computing
> http://www.boostpro.com
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Yes there is a way. I haven't used it myself but search this list and you'll find plenty of references.

(disclaimer: the following is what I think you can do based on some vague recollection and some man pages)

Taking a quick look at the git push --help you'll see the following snippet of configuration.

                   [remote "<name>"]
                           url = <url>
                           pushurl = <pushurl>
                           push = <refspec>
                           fetch = <refspec>

so I think if you just add the pushurl to your .git/config should do what you've asked

[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = git://git.kernel.org/pub/scm/git/git.git
        pushurl = git://git.example.com/yourrepo.git

For your own sanity I suggest doing this by adding your repository as a separate remote.

e.g.
  git remote add yourrepo git://git.example.com/yourrepo.git
  git push yourrepo master:refs/heads/master  # the first time
  git push yourrepo # subsequent times

There probably is a way to tell push to use something other than "origin" by default but I don't know/can't find it.

Jeff King· Feb 12, 2010, 00:14 UTC · re: Chris Packham · lore

Re: Separate default push/pull?

On Thu, Feb 11, 2010 at 01:57:34PM -0500, Chris Packham wrote:
Show 16 quoted lines
> Taking a quick look at the git push --help you'll see the following
> snippet of configuration.
> 
>                    [remote "<name>"]
>                            url = <url>
>                            pushurl = <pushurl>
>                            push = <refspec>
>                            fetch = <refspec>
> 
> so I think if you just add the pushurl to your .git/config should do
> what you've asked
> 
> [remote "origin"]
>         fetch = +refs/heads/*:refs/remotes/origin/*
>         url = git://git.kernel.org/pub/scm/git/git.git
>         pushurl = git://git.example.com/yourrepo.git

That's not quite what David wants, I think. That is a good recipe if you have two ways of accessing the same repo (usually git:// for reading and ssh for pushing). But if the two URLs actually point to _different_ repos, you will get some confusing results. For example, pushing to your private repo will update the tracking branches in refs/remotes/origin/* with values that do not match what is in the actual origin repository.

Show 6 quoted lines
>   git remote add yourrepo git://git.example.com/yourrepo.git
>   git push yourrepo master:refs/heads/master  # the first time
>   git push yourrepo # subsequent times
> 
> There probably is a way to tell push to use something other than
> "origin" by default but I don't know/can't find it.

I don't think there is currently a way to do what he wants. You can set a default remote name by setting branch.*.remote, but that has two problems:

  1. It is also used to determine the upstream remote for pulling and
     for calculating upstream tracking branches. So he probably wants to
     leave it set as origin.
  2. It would have to be set manually for every branch.

I think what he would need is a "push.defaultRemote" config option, which universally overrides branch.*.remote for pushing.

-Peff
Junio C Hamano· Feb 12, 2010, 00:49 UTC · re: Jeff King · lore

Re: Separate default push/pull?

Jeff King <peff@peff.net> writes:
> I think what he would need is a "push.defaultRemote" config option,
> which universally overrides branch.*.remote for pushing.
Or "branch.*.pushremote".

But does it really make sense to get changes from one place and send changes to somewhere completely unrelated?

Jeff King· Feb 12, 2010, 01:05 UTC · re: Junio C Hamano · lore

Re: Separate default push/pull?

On Thu, Feb 11, 2010 at 04:49:26PM -0800, Junio C Hamano wrote:
Show 6 quoted lines
> Jeff King <peff@peff.net> writes:
> 
> > I think what he would need is a "push.defaultRemote" config option,
> > which universally overrides branch.*.remote for pushing.
> 
> Or "branch.*.pushremote".

That doesn't address my point 2, which is needing to set it up for every branch.

> But does it really make sense to get changes from one place and send
> changes to somewhere completely unrelated?

It depends on your workflow. For git.git, your kernel.org repository is my "origin", but I publish my state to a mirror for backup purposes (and I don't publish for others to view, but I could very well do that, too). I type "git push peff.net" and that is not too much trouble. Typing just "git push" would be slightly more convenient, though.

In a distributed setup, I don't think it is that uncommon to not want to push to the place you pull from. You are generally pulling and building on somebody else's work, so if there is no central repo, you will be pushing to somewhere that is not where you pulled it.

-Peff
Junio C Hamano· Feb 12, 2010, 05:57 UTC · re: Jeff King · lore

Re: Separate default push/pull?

Jeff King <peff@peff.net> writes:
> In a distributed setup, I don't think it is that uncommon to not want to
> push to the place you pull from. You are generally pulling and building
> on somebody else's work, so if there is no central repo, you will be
> pushing to somewhere that is not where you pulled it.
You are probably right.

It still feels funny to see "git pull" and "git push" goes to different places, but as long as that is what the user explicitly configures, that's fine.

Jeff King· Feb 13, 2010, 11:58 UTC · re: Junio C Hamano · lore

Re: Separate default push/pull?

On Thu, Feb 11, 2010 at 09:57:54PM -0800, Junio C Hamano wrote:
Show 12 quoted lines
> Jeff King <peff@peff.net> writes:
> 
> > In a distributed setup, I don't think it is that uncommon to not want to
> > push to the place you pull from. You are generally pulling and building
> > on somebody else's work, so if there is no central repo, you will be
> > pushing to somewhere that is not where you pulled it.
> 
> You are probably right.
> 
> It still feels funny to see "git pull" and "git push" goes to different
> places, but as long as that is what the user explicitly configures, that's
> fine.

By the way, I am a little iffy on the configuration I suggested. Even though it matches David's workflow, it seems unintuitive to me that a "push.defaultremote" variable would override what's in "branch.*.remote".

-Peff
David Abrahams· Feb 12, 2010, 02:32 UTC · re: Junio C Hamano · lore

Re: Separate default push/pull?

At Thu, 11 Feb 2010 16:49:26 -0800, Junio C Hamano wrote:

Show 10 quoted lines
> 
> Jeff King <peff@peff.net> writes:
> 
> > I think what he would need is a "push.defaultRemote" config option,
> > which universally overrides branch.*.remote for pushing.
> 
> Or "branch.*.pushremote".
> 
> But does it really make sense to get changes from one place and send
> changes to somewhere completely unrelated?

It's not unrelated; it's a publicly-readable clone of the source repo to which I have write permission. After pushing changes there I send a pull request to the owner of the source repo.

-- 
Dave Abrahams           Meet me at BoostCon: http://www.boostcon.com
BoostPro Computing
http://www.boostpro.com

← back to recent threads