Separate default push/pull?

Separate default push/pull?

[David Abrahams]

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

Re: Separate default push/pull?

[Chris Packham]

On Thu, Feb 11, 2010 at 11:36 AM, David Abrahams <dave@boostpro.com> wrote:
>
> 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.

Re: Separate default push/pull?

[Jeff King]

On Thu, Feb 11, 2010 at 01:57:34PM -0500, Chris Packham wrote:

> 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.

>   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

Re: Separate default push/pull?

[Junio C Hamano]

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?

Re: Separate default push/pull?

[Jeff King]

On Thu, Feb 11, 2010 at 04:49:26PM -0800, Junio C Hamano wrote:

> 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

Re: Separate default push/pull?

[David Abrahams]

At Thu, 11 Feb 2010 16:49:26 -0800,
Junio C Hamano wrote:
> 
> 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

Re: Separate default push/pull?

[Junio C Hamano]

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.

Re: Separate default push/pull?

[Jeff King]

On Thu, Feb 11, 2010 at 09:57:54PM -0800, Junio C Hamano wrote:

> 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