Proposal: branch.<name>.remotepush

Proposal: branch.<name>.remotepush

[Ramkumar Ramachandra]

Hi,

This has been annoying me for a really long time, but I never really
got around to scratching this particular itch.  I have a very common
scenario where I fork a project on GitHub.  I have two configured
remotes: origin which points to "git://upstream" and mine which points
to "ssh://mine".  By default, I always want to pull `master` from
origin and push to mine.  Unfortunately, there's only a
branch.<name>.remote which specifies which remote to use for both
pulling and pushing.  There's also a remote.<name>.pushurl, but I get
the feeling that this exists for an entirely different reason: when I
have a server with a highly-available read-only mirror of the
repository at git://anongit.*, and a less-available committer-only
mirror at ssh://*.

How about a branch.<name>.remotepush that specifies a special remote
for pushing, falling back to branch.<name>.remote?

Ram

Re: Proposal: branch.<name>.remotepush

[Michael Schubert]

On 02/07/2013 05:14 PM, Ramkumar Ramachandra wrote:

> This has been annoying me for a really long time, but I never really
> got around to scratching this particular itch.  I have a very common
> scenario where I fork a project on GitHub.  I have two configured
> remotes: origin which points to "git://upstream" and mine which points
> to "ssh://mine".  By default, I always want to pull `master` from
> origin and push to mine.  Unfortunately, there's only a
> branch.<name>.remote which specifies which remote to use for both
> pulling and pushing.  There's also a remote.<name>.pushurl, but I get
> the feeling that this exists for an entirely different reason: when I
> have a server with a highly-available read-only mirror of the
> repository at git://anongit.*, and a less-available committer-only
> mirror at ssh://*.
> 
> How about a branch.<name>.remotepush that specifies a special remote
> for pushing, falling back to branch.<name>.remote?

Additionally, it would be nice to have branch.<name>.push or similar
to configure a default destination branch for push. Gerrit users usually
want to track refs/heads/master but push to refs/for/master for example.

Re: Proposal: branch.<name>.remotepush

[Ramkumar Ramachandra]

There's a reason why remote.<name>.pushurl feels wrong.  If one remote
has a different push from pull, there should be something
corresponding to refs/remotes/* for push (and the equivalent of fetch
for updating it).  Second, I can't even diff between a branch on my
push URL and a local branch: the [ahead 1, behind 1] in status output
really doesn't make sense if the repository you're pushing to is
different from the one you're pulling from.  In contrast, if you take
what I proposed, refs/remotes/{upstream, mine}/* already exist, and
it's easy to diff them with the corresponding local branch.

And yes, a regular `git push origin refs/for/master` is just retarded.
 I don't personally use Gerrit, but the people who do should not have
to suffer.

Re: Proposal: branch.<name>.remotepush

[Ramkumar Ramachandra]

Ramkumar Ramachandra wrote:
> And yes, a regular `git push origin refs/for/master` is just retarded.

Actually a git config remote.origin.push refs/heads/*:refs/for/* makes
more sense here.

Re: Proposal: branch.<name>.remotepush

[Ramkumar Ramachandra]

Ramkumar Ramachandra wrote:
> Ramkumar Ramachandra wrote:
>> And yes, a regular `git push origin refs/for/master` is just retarded.
>
> Actually a git config remote.origin.push refs/heads/*:refs/for/* makes
> more sense here.

Sorry about all that confusion.  The first line should be `git push
origin master:refs/for/master`, but a rule like refs/head/*:refs/for/*
is insufficient: what if I want refs/head/*:refs/heads/* for one set
of branches (private ones that I don't send for review), and
refs/heads/*:refs/for/* for another set (which I send for review)?
That certainly won't play well will the existing remote.origin.push;
it'd have to behave as an override.

Re: Proposal: branch.<name>.remotepush

[Jonathan Nieder]

Hi Ram,

Ramkumar Ramachandra wrote:

> And yes, a regular `git push origin refs/for/master` is just retarded.

The usual incantation is "git push gerrit HEAD:refs/for/master".  Is
the code review creation push that uses a different branchname from
the branch the integrator pulls what seems backward, or is it the need
to specify a refname at all on the command line?

I agree that a "[branch "master"] pushremote" configuration would be
handy.  pushremote instead of remotepush to be less surprising to
people who have already seen pushurl.

Good luck,
Jonathan

Re: Proposal: branch.<name>.remotepush

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

> The usual incantation is "git push gerrit HEAD:refs/for/master".  Is
> the code review creation push that uses a different branchname from
> the branch the integrator pulls what seems backward, or is it the need
> to specify a refname at all on the command line?
>
> I agree that a "[branch "master"] pushremote" configuration would be
> handy.  pushremote instead of remotepush to be less surprising to
> people who have already seen pushurl.

I'd actually see this as Gerrit being weird.

If it wants to quarantine a commit destined to the "master" branch,
couldn't it just let people push to "master" and then internally
update "for/master" instead?

Re: Proposal: branch.<name>.remotepush

[Jeff King]

On Thu, Feb 07, 2013 at 09:44:59PM +0530, Ramkumar Ramachandra wrote:

> This has been annoying me for a really long time, but I never really
> got around to scratching this particular itch.  I have a very common
> scenario where I fork a project on GitHub.  I have two configured
> remotes: origin which points to "git://upstream" and mine which points
> to "ssh://mine".  By default, I always want to pull `master` from
> origin and push to mine.

Same here. Even without GitHub, working on git.git I treat Junio as my
"origin", but push to a publishing point.

> Unfortunately, there's only a branch.<name>.remote which specifies
> which remote to use for both pulling and pushing.  There's also a
> remote.<name>.pushurl, but I get the feeling that this exists for an
> entirely different reason: when I have a server with a
> highly-available read-only mirror of the repository at
> git://anongit.*, and a less-available committer-only mirror at
> ssh://*.

Yeah, you don't want to use pushurl. It makes the assumption that you
are pushing to the same remote, so when you, e.g., push to the remote's
refs/heads/master, it will update refs/remotes/origin/master. But that's
not right; that ref should be tracking the true origin, not what you
pushed to.

> How about a branch.<name>.remotepush that specifies a special remote
> for pushing, falling back to branch.<name>.remote?

Sure, though I wonder if you really want a per-branch config, or if you
just want remote.pushDefault or similar, so that you do not have to
configure each branch independently as you create it. I'm imagining
lookup rules something like:

  1. If we are on branch $b, check branch.$b.pushRemote.

  2. If not set, check remote.pushDefault.

  3. If not set, check branch.$b.remote.

  4. If not set, check remote.default (there was a proposal for this a
     few months ago, but it got stalled).

  5. If not set, use "origin".

And then fetching could do the same, with s/push/fetch/. In both cases,
if you are not using the new variables, the behavior is the same as
the current behavior.

-Peff

Re: Proposal: branch.<name>.remotepush

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Thu, Feb 07, 2013 at 09:44:59PM +0530, Ramkumar Ramachandra wrote:
>
>> This has been annoying me for a really long time, but I never really
>> got around to scratching this particular itch.  I have a very common
>> scenario where I fork a project on GitHub.  I have two configured
>> remotes: origin which points to "git://upstream" and mine which points
>> to "ssh://mine".  By default, I always want to pull `master` from
>> origin and push to mine.
>
> Same here. Even without GitHub, working on git.git I treat Junio as my
> "origin", but push to a publishing point.

The "you fetch from and push to the same place" semantics that
associates a branch to a single remote was primarily done for people
coming from CVS/SVN background [*1*].  I think the triangle
arrangement where you want to have "this is where I fetch from and
integrate with, and that is where I publish" is more common among
the Git users these days.

How best to express the triangle is somewhat tricky, but I think it
is sensible to say you have "origin" that points to your upstream
(i.e. me), and "peff" that points to your publishing point, in other
words, make it explicit that the user deals with two remotes.  Then
have push.default name the remote "peff", so that "git push" goes to
that remote by default (and have "git fetch/pull" go to "origin).
You will have two sets of remote tracking branches (one from "origin"
that your push will never pretend to have fetched immediately after
finishing, the other from "peff" that keeps track of what you pushed
the last time).

Of course, some people may have "I use this and that branches to
interact with upstream X while I use these other branches to
interacct with upstream Y, and all of them push to different
places", and supporting that may need complex per branch "On this
branch fetch from and integrate with remote X, and push to remote Z"
settings, but as you said, "I fetch from and integrate with X, and
result is pushed out to Y" should be the most common, and it would
be desirable to have a simple way to express it with just a single
new configuration variable.


[Footnote]

*1* It also happens to work reasonably well for people like Linus
and I with the "I pull from random places, I locally integrate and I
publish the results" workflow, because we are trained to think that
it is not just being lazy but simply meaningless to say "git pull"
without saying "fetch and integrate _what_ and from _whom_", and
that is only because we do not have a fixed upstream.  Linus and I
would practically never fetch from "origin", i.e. from ourselves.

Re: Proposal: branch.<name>.remotepush

[Jeff King]

On Thu, Feb 07, 2013 at 10:08:48PM -0800, Junio C Hamano wrote:

> How best to express the triangle is somewhat tricky, but I think it
> is sensible to say you have "origin" that points to your upstream
> (i.e. me), and "peff" that points to your publishing point, in other
> words, make it explicit that the user deals with two remotes.  Then
> have push.default name the remote "peff", so that "git push" goes to
> that remote by default (and have "git fetch/pull" go to "origin).
> You will have two sets of remote tracking branches (one from "origin"
> that your push will never pretend to have fetched immediately after
> finishing, the other from "peff" that keeps track of what you pushed
> the last time).

Exactly. That is what I have set up now, except that I have to type "git
push peff" because there is no such push.default (with the minor nit
that push.default does something else, so the config should be called
remote.pushDefault or something). The entirety of the feature would be
saving the user from the annoyance of:

  $ git push
  fatal: remote error:
    You can't push to git://github.com/gitster/git.git
    Use git@github.com:gitster/git.git

  [doh! Stupid git, why don't you do what I mean, not what I say?]
  $ git push peff
  ... it works ...

> Of course, some people may have "I use this and that branches to
> interact with upstream X while I use these other branches to
> interacct with upstream Y, and all of them push to different
> places", and supporting that may need complex per branch "On this
> branch fetch from and integrate with remote X, and push to remote Z"
> settings, but as you said, "I fetch from and integrate with X, and
> result is pushed out to Y" should be the most common, and it would
> be desirable to have a simple way to express it with just a single
> new configuration variable.

Right. Frankly, I do not care that much about the per-branch push remote
myself. In the rules I gave earlier, that was my complete
backwards-compatible vision, so that we do not paint ourselves into a
corner compatibility-wise when somebody wants it later. Just
implementing the default push remote part would be a fine first step.

I also indicated in my rules that we could have a branch.*.fetchRemote,
as well, but I do not think it is strictly necessary. I think the
non-specific branch.*.remote could continue to be used for fetching, and
as a backup when the push-specific variables are not set.

> *1* It also happens to work reasonably well for people like Linus
> and I with the "I pull from random places, I locally integrate and I
> publish the results" workflow, because we are trained to think that
> it is not just being lazy but simply meaningless to say "git pull"
> without saying "fetch and integrate _what_ and from _whom_", and
> that is only because we do not have a fixed upstream.  Linus and I
> would practically never fetch from "origin", i.e. from ourselves.

Right, I think "git pull" is more useful in a centralized repo setting
where there is one branch and one repo, so there is no "what and whom"
to specify. Personally I do not use it much at all, as I do a separate
fetch, inspect, and merge, but that is somewhat orthogonal to your
reasons. :)

-Peff

Re: Proposal: branch.<name>.remotepush

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> ....  I think the triangle
> arrangement where you want to have "this is where I fetch from and
> integrate with, and that is where I publish" is more common among
> the Git users these days.

Another thing to know about is that the recent move to change the
behaviour of "git push" to work only on one branch per default may
have to be polished and strengthened a bit.

Originally, the encouraged workflow was to perfect _everything_ that
you would push out and then with a single "git push" to publish
everything at the same time.  Both the "matching" behaviour of "git
push" which was the default, and the set of push refspecs that is to
be defined per remote, were ways to discourage "Work on one branch,
think it is OK, hastily push only that branch out, switch to another
branch, rinse, repeat".

To support a triangular arrangement well, there may need some
thinking on what $branch@{upstream} means.  The original intent of
the upstream mode specified for "push.default" is push the result
back to what you based your work on, but in a triangular arrangement
that is no longer true.  You may be keeping up with my 'master' by
constantly rebasing and then pushing out the result to your 'frotz'
topic.  You want to have a lazy "git fetch" to fetch from my
'master' (i.e. upstream), and have remotes/origin/master to keep
track of it.  You want to see "git rebase" to pay attention to the
updates to remotes/origin/master when figuring out where you forked.
But at the same time, you want a lazy "git push" to go to your
push.defaultTo repository (i.e. your publish point) and update your
'frotz' branch there---remotes/origin/master should not come into
the picture at all.  But the upstream and simple modes want to pay
attention to branch.$name.merge, which is all about the "fetch and
integrate" side of the equation.

Re: Proposal: branch.<name>.remotepush

[Jonathan Nieder]

Junio C Hamano wrote:

> I'd actually see this as Gerrit being weird.
>
> If it wants to quarantine a commit destined to the "master" branch,
> couldn't it just let people push to "master" and then internally
> update "for/master" instead?

It is because pushing doesn't update refs/heads/master.  Instead, it
starts a code review.

Suppose Gerrit allows starting a new code review by pushing to
refs/heads/master.  It sounds okay if I squint --- it's just a very
slow asynchronous ref update, right?  Let's see:

	$ git clone <gerrit server> test
	Cloning into 'test'...
	$ echo hi >greeting
	$ git add greeting
	$ git commit -q -m 'hello'
	$ git push origin master
[...]
	remote: New Changes:
	remote:   <gerrit server>/r/1234
	remote: 
	To <url>
	   ea4cb77b..9117390e  master -> master
	$ : walk away, forget what I was doing
	$ git fetch origin
	From <url>
	 + 9117390...ea4cb77 master     -> origin/master  (forced update)

"Wait, why did the remote rewind?"

Regards,
Jonathan

Re: Proposal: branch.<name>.remotepush

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

> "Wait, why did the remote rewind?"

Oh, I am very well aware of that glitch.

"git push" has this hack to pretend as if the pusher immediately
turned around and fetched from the remote.

It shouldn't have been made to do so unconditionally; instead it
should have been designed to give the pushee a way to optionally
tell you "I acccept this push, but you may not see it to be updated
to that exact value you pushed when you fetched from me right now".

The hack is not my design; it was not even something I accepted
without complaints, so I can badmouth about it all I want without
hesitation ;-)

More importantly, we could fix it if we wanted to.

Re: Proposal: branch.<name>.remotepush

[Jeff King]

On Thu, Feb 07, 2013 at 10:45:07PM -0800, Junio C Hamano wrote:

> To support a triangular arrangement well, there may need some
> thinking on what $branch@{upstream} means.  The original intent of
> the upstream mode specified for "push.default" is push the result
> back to what you based your work on, but in a triangular arrangement
> that is no longer true.

I don't think that "upstream" or "simple" push settings really make
sense in such a triangular arrangement. And IMHO, that's OK. They
reflect a much simpler view of the world than git is capable of
supporting. So "simple" works OK as a default, and people can move to
"matching" (or "current", or even a custom refspec) once they have are
ready to take advantage of a more advanced topology/workflow.

We have the problem now that new users do not necessarily understand the
matching strategy, or why it is useful, and get confused. When we move
to "simple", we may be switching to a world where the early part of the
learning curve is more gentle for those users, but they eventually run
across the steeper part when they want to adjust their workflow (i.e.,
they will eventually learn about non-symmetric repo topologies because
those are part of many useful workflows).

But I think it's a good thing to push that part of the learning curve
out, because:

  1. Some people may stay in the centralized view their whole lives and
     never care.

  2. It will make more sense to them, because they'll understand how it
     fits into what they're trying to do, rather than viewing it as an
     arcane and senseless default.

There may be some confusion as people hit that learning point. I won't
be surprised if we end up adding more advice.* messages in certain cases
to guide people to adjusting their push.default. But I'm just as happy
to wait until people start hitting the confusion point in practice, and
we can see more clearly when that advice should trigger, and what it
should say.

Unless you have ideas now, of course, in which case I'm happy to hear
them. :)

-Peff

Re: Proposal: branch.<name>.remotepush

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
> Jonathan Nieder <jrnieder@gmail.com> writes:
> 
>> "Wait, why did the remote rewind?"
> 
> Oh, I am very well aware of that glitch.
> 
> "git push" has this hack to pretend as if the pusher immediately
> turned around and fetched from the remote.
> 
> It shouldn't have been made to do so unconditionally; instead it
> should have been designed to give the pushee a way to optionally
> tell you "I acccept this push, but you may not see it to be updated
> to that exact value you pushed when you fetched from me right now".
> 
> The hack is not my design; it was not even something I accepted
> without complaints, so I can badmouth about it all I want without
> hesitation ;-)
> 
> More importantly, we could fix it if we wanted to.

And this seems to be more natural, too. It can keep the internals (the
auxiliary ref on the server side) hidden from the user.

As for the triangle remote, I really think we should clean up the
situation regarding push, pushurlinsteadof and the various different and
inconclusive output formats of "git remote" (with or without "-v", with
or without a remote name) first, before introducing yet another way to
twist things around. "git push downstream" does not hurt any kittens
(while git remote ouput does, somehwat).

Michael

Re: Proposal: branch.<name>.remotepush

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> We have the problem now that new users do not necessarily understand the
> matching strategy, or why it is useful, and get confused. When we move
> to "simple", we may be switching to a world where the early part of the
> learning curve is more gentle for those users, but they eventually run
> across the steeper part when they want to adjust their workflow (i.e.,
> they will eventually learn about non-symmetric repo topologies because
> those are part of many useful workflows).
>
> But I think it's a good thing to push that part of the learning curve
> out, because:
>
>   1. Some people may stay in the centralized view their whole lives and
>      never care.
>
>   2. It will make more sense to them, because they'll understand how it
>      fits into what they're trying to do, rather than viewing it as an
>      arcane and senseless default.
>
> There may be some confusion as people hit that learning point. I won't
> be surprised if we end up adding more advice.* messages in certain cases
> to guide people to adjusting their push.default. But I'm just as happy
> to wait until people start hitting the confusion point in practice, and
> we can see more clearly when that advice should trigger, and what it
> should say.

Oh, I agree with you that adding new support for triangular workflow
will not hurt the centralized folks.  I was more interested about
helping the "fetch from here, push to there" people.

Centralized people do not have to configure anything for each branch
for "git push" to push their current branch to where they fetch from
and to the same name (you start building on their 'master', your
result go to their 'master', because as a centralized person, you
are part of 'them').  They have branch.$name.merge that names what
their $name branch merges with, and that is sufficient to decide to
which branch the result is to be pushed back.  

With the "push.defaultTo = peff" to name what remote the "git push"
will push to, or even with the "branch.master.remotepush = peff" to
decide that per branch, would "fetch from here, push to there"
people have a way similar to what branch.$name.merge gives to the
centralized people to decide what branch is updated?

It almost seems to me that we may want to extend the semantics given
to the remote.$name.push refspecs.  They are primarily for "perfect
all branches you are going to push out, and push them in one go with
'git push'" workflow, but if it is clear that you are not following
that (e.g. you are doing an equivalent of what the centralized folks
would do with "push.default = simple/upstream/current") and pushing
only the current branch, perhaps we should look at these refspecs to
see where the current branch goes?

In your case, 'refs/heads/master' would likely to go to
'refs/heads/master', and we could treat a missing remote.peff.push  
an equivalent to having remote.peff.push = refs/heads/*:refs/heads/*

In a Gerrit user's case brought up by Michael Schubert in a message
earlier in the near-by subthread, 'refs/heads/frotz' would likely to
go to 'refs/for/frotz' and they can express it with something like

	[remote "origin"]
		url = ... ;# pushurl is the same or just s/git/ssh/;
                fetch = refs/heads/*:refs/heads/*
                push = refs/heads/*:refs/for/*
	[push]
		default = "???"

where "???" says "I push out only the currently checked-out branch;
figure out where it goes using remote.origin.push refspec".

Having to set both branch.$name.remotepush to name what remote this
branch should be pushed, and branch.$name.branchpush to name what
branch at the remote this branch should update with a push, and
doing so for each and every branch, sounds like an unnecessary
complexity.

Re: Proposal: branch.<name>.remotepush

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> As for the triangle remote, I really think we should clean up the
> situation regarding push, pushurlinsteadof and the various different and
> inconclusive output formats of "git remote" (with or without "-v", with
> or without a remote name) first, before introducing yet another way to
> twist things around. "git push downstream" does not hurt any kittens
> (while git remote ouput does, somehwat).

As people tend to fetch more often than they push if they are
working on a real project where the others as a whole will be far
more productive than any single individual, I agree that keeping
"git fetch" (or "git pull") lazy by having "origin" point at where
they fetch from and be a bit more explicit in "git push" would
actually make sense.

Re: Proposal: branch.<name>.remotepush

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>> 
>>> "Wait, why did the remote rewind?"
>> 
>> Oh, I am very well aware of that glitch.
>> 
>> "git push" has this hack to pretend as if the pusher immediately
>> turned around and fetched from the remote.
>> 
>> It shouldn't have been made to do so unconditionally; instead it
>> should have been designed to give the pushee a way to optionally
>> tell you "I acccept this push, but you may not see it to be updated
>> to that exact value you pushed when you fetched from me right now".
>> 
>> The hack is not my design; it was not even something I accepted
>> without complaints, so I can badmouth about it all I want without
>> hesitation ;-)
>> 
>> More importantly, we could fix it if we wanted to.
>
> And this seems to be more natural, too. It can keep the internals (the
> auxiliary ref on the server side) hidden from the user.

Fixing that misfeature to always pretend it immediately turned
around and fetched may have a different benefit, too.

A straightforward and simple solution to Ram's original problem may
be to define pushurl to point at his publishing repository after
all, and teach "git push" not to pretend it immediately fetched with
the same "fix".

	[remote "origin"]
        	url = ... where Ram fetches and pulls from ...
                pushurl = ... where Ram pushes to ...
                fetch = refs/heads/*:refs/remotes/*
		updateTrackOnPush = no

Then "git fetch" (or "git pull") will update the remote tracking
branches Ram fetches from, and once his topic is finished, he can
push to his publishing location, which won't touch the remote
tracking branches used to keep track of the place he fetches from.

Re: Proposal: branch.<name>.remotepush

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
>> We have the problem now that new users do not necessarily understand the
>> matching strategy, or why it is useful, and get confused. When we move
>> to "simple", we may be switching to a world where the early part of the
>> learning curve is more gentle for those users, but they eventually run
>> across the steeper part when they want to adjust their workflow (i.e.,
>> they will eventually learn about non-symmetric repo topologies because
>> those are part of many useful workflows).
>>
>> But I think it's a good thing to push that part of the learning curve
>> out, because:
>>
>>   1. Some people may stay in the centralized view their whole lives and
>>      never care.
>>
>>   2. It will make more sense to them, because they'll understand how it
>>      fits into what they're trying to do, rather than viewing it as an
>>      arcane and senseless default.
>>
>> There may be some confusion as people hit that learning point. I won't
>> be surprised if we end up adding more advice.* messages in certain cases
>> to guide people to adjusting their push.default. But I'm just as happy
>> to wait until people start hitting the confusion point in practice, and
>> we can see more clearly when that advice should trigger, and what it
>> should say.
>
> Oh, I agree with you that adding new support for triangular workflow
> will not hurt the centralized folks.  I was more interested about
> helping the "fetch from here, push to there" people.

In Git, there will always be a combination of switches which allows
you to go the centralized workflow mode.  We're focusing on expanding
this list of switches, to free up distributed workflows into more
possibilities.  We're currently targeting problems that affect us
everyday; the ones we've failed to notice.

> Centralized people do not have to configure anything for each branch
> for "git push" to push their current branch to where they fetch from
> and to the same name (you start building on their 'master', your
> result go to their 'master', because as a centralized person, you
> are part of 'them').  They have branch.$name.merge that names what
> their $name branch merges with, and that is sufficient to decide to
> which branch the result is to be pushed back.

What about the branch.$name.pushRef, which was proposed earlier?  They
should be able to say, at a per-branch level, which branches to send
for review (in Gerrit).

> With the "push.defaultTo = peff" to name what remote the "git push"
> will push to, or even with the "branch.master.remotepush = peff" to
> decide that per branch, would "fetch from here, push to there"
> people have a way similar to what branch.$name.merge gives to the
> centralized people to decide what branch is updated?

Ah.

> It almost seems to me that we may want to extend the semantics given
> to the remote.$name.push refspecs.  They are primarily for "perfect
> all branches you are going to push out, and push them in one go with
> 'git push'" workflow, but if it is clear that you are not following
> that (e.g. you are doing an equivalent of what the centralized folks
> would do with "push.default = simple/upstream/current") and pushing
> only the current branch, perhaps we should look at these refspecs to
> see where the current branch goes?

I'd actually just go with the current syntax + per-branch overrides.
Simple and serves the purpose: I don't think there'll be real usecases
outside this.

> In your case, 'refs/heads/master' would likely to go to
> 'refs/heads/master', and we could treat a missing remote.peff.push
> an equivalent to having remote.peff.push = refs/heads/*:refs/heads/*

I'll get to work on a patch that deems the configuration variable as
not "necessary".

Re: Proposal: branch.<name>.remotepush

[Ramkumar Ramachandra]

Junio C Hamano wrote:
>         [remote "origin"]
>                 url = ... where Ram fetches and pulls from ...
>                 pushurl = ... where Ram pushes to ...
>                 fetch = refs/heads/*:refs/remotes/*
>                 updateTrackOnPush = no
>
> Then "git fetch" (or "git pull") will update the remote tracking
> branches Ram fetches from, and once his topic is finished, he can
> push to his publishing location, which won't touch the remote
> tracking branches used to keep track of the place he fetches from.

A "push" should never touch remote/refs/origin/* if there is a pushurl
configured.  Otherwise, it should.  I want my push to affect my
status.  The configuration variable makes no sense and should not
exist.

Unfortunately, pushurl doesn't get the same privileges as url even
though they're equal remotes.  How is my fork "inferior" to the
upstream project in any way?  A lot of us might be working on this
fork, and we will need something corresponding to refs/remotes/* to
inspect its state.  Like I said earlier, I think pushurl has a very
limited usecase: when the two URLs are actually mirrors (there is
really no fork; we're back in a centralized environment).  In fact, I
think it should be deprecated, because it interferes with my more
general approach.

Let's see what happens if we have two actual remotes.
remote/refs/origin/* will be updated when I fetch from, and push to,
origin.   remote/refs/ram/* will be updated when I fetch from, and
push to, ram.  It's very simple, and I don't need this complex rule of
when to update refs.  We should have a way to pair remotes together as
upstream/ downstream in the future.  Maybe even have a hierarchy of
remotes.

Re: Proposal: branch.<name>.remotepush

[Jonathan Nieder]

Michael J Gruber wrote:
> Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
>> Jonathan Nieder <jrnieder@gmail.com> writes:

>>> "Wait, why did the remote rewind?"
>>
>> Oh, I am very well aware of that glitch.
>>
>> "git push" has this hack to pretend as if the pusher immediately
>> turned around and fetched from the remote.
>> 
>> It shouldn't have been made to do so unconditionally; instead it
>> should have been designed to give the pushee a way to optionally
>> tell you "I acccept this push, but you may not see it to be updated
>> to that exact value you pushed when you fetched from me right now".

Yes, I agree with this.

The "git push" hack does seem to be useful in practice for helping
people just starting to use git.  If they have a separate "gitk --all"
window open, they can refresh it and see the remote-tracking branch
corresponding to the branch that has been pushed advancing.  It matches
a model in which remote-tracking refs represent "git's idea of where
these branches are in the remote repository".

And in that model, a remote being able to respond to a push with
"ref update queued, but please keep in mind that it may take me a
while to chew through that queue" should be perfectly reasonable.

[...]
> And this seems to be more natural, too. It can keep the internals (the
> auxiliary ref on the server side) hidden from the user.

Just to clarify: this is not an internal ref being exposed.  No
auxiliary refs/for/master ref actually exists.  The ref Gerrit users
push to is a UI fiction.

That's important because otherwise two developers could not propose
changes for the same branch at the same time.

Jonathan

Re: Proposal: branch.<name>.remotepush

[Ramkumar Ramachandra]

Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> And yes, a regular `git push origin refs/for/master` is just retarded.
>
> The usual incantation is "git push gerrit HEAD:refs/for/master".  Is
> the code review creation push that uses a different branchname from
> the branch the integrator pulls what seems backward, or is it the need
> to specify a refname at all on the command line?

How else would you design a system to differentiate between a
push-for-review, and push-to-update-ref?

On a slightly unrelated note, it would be nice if we could streamline
the git-format-patch, git-send-email process.  Let's say we make it a
push', which has a pre-hook that fires up the $EDITOR for a cover
letter.  Wouldn't you love it if this push' would update refs on your
private fork and fire off emails to the Git List?  Bonus for contrib/:
fetch the Google address book, and allow me to auto-complete names
when sending emails.

> I agree that a "[branch "master"] pushremote" configuration would be
> handy.  pushremote instead of remotepush to be less surprising to
> people who have already seen pushurl.

Thanks for that, by the way (used in RFC patch).  My taste in variable
names is a little sour.

Re: Proposal: branch.<name>.remotepush

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Junio C Hamano wrote:
>>         [remote "origin"]
>>                 url = ... where Ram fetches and pulls from ...
>>                 pushurl = ... where Ram pushes to ...
>>                 fetch = refs/heads/*:refs/remotes/*
>>                 updateTrackOnPush = no
>>
>> Then "git fetch" (or "git pull") will update the remote tracking
>> branches Ram fetches from, and once his topic is finished, he can
>> push to his publishing location, which won't touch the remote
>> tracking branches used to keep track of the place he fetches from.
>
> A "push" should never touch remote/refs/origin/* if there is a pushurl
> configured.  Otherwise, it should.

That is a horrible design, no?

Because one of the main use case for pushurl is to use url = git://
for less overhead and pushurl = ssh+git:// for authentication but
otherwise going to the same place.  So if "git push" is allowed to
pretend you immediately turned around and fetched, push to that
pushurl will pretend it was followed by a fetch from the
corresponding url.

You need a way to tell if the pushurl/url pair is used for that
purpose to let Git know if that is the case.

Re: Proposal: branch.<name>.remotepush

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Jonathan Nieder wrote:
>> Ramkumar Ramachandra wrote:
>>
>>> And yes, a regular `git push origin refs/for/master` is just retarded.
>>
>> The usual incantation is "git push gerrit HEAD:refs/for/master".  Is
>> the code review creation push that uses a different branchname from
>> the branch the integrator pulls what seems backward, or is it the need
>> to specify a refname at all on the command line?
>
> How else would you design a system to differentiate between a
> push-for-review, and push-to-update-ref?

You don't have to.

If the reviewed result is merged on the server side and appear on
'master', nobody has to push to update refs/heads/master.

Re: Proposal: branch.<name>.remotepush

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> Jonathan Nieder wrote:
>>> Ramkumar Ramachandra wrote:
>>>
>>>> And yes, a regular `git push origin refs/for/master` is just retarded.
>>>
>>> The usual incantation is "git push gerrit HEAD:refs/for/master".  Is
>>> the code review creation push that uses a different branchname from
>>> the branch the integrator pulls what seems backward, or is it the need
>>> to specify a refname at all on the command line?
>>
>> How else would you design a system to differentiate between a
>> push-for-review, and push-to-update-ref?
>
> You don't have to.
>
> If the reviewed result is merged on the server side and appear on
> 'master', nobody has to push to update refs/heads/master.

I'm sorry, I meant differentiating between push-for-review and
push-for-personal-work.