Re: Random thoughts on "upstream"

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Please clarify the semantics of @{f}. Does it conceptually refer to where the current branch is going to be pushed to (i.e. a pair of (<remote>, <ref>))? Will we have a remote tracking branch for it to record what we pushed there the last time? I am guessing that your answers to both of these questions are "Yes", and frotz@{f} would resolve to refs/remotes/there/topics/frotz-for-juno in the sample set-up in the message you are responding to.

	Side note: I do not think "fork" rings bell to the end
	users.  Who is forking from what?  I am guessing you are
	trying to make a short form of "the branch in my public
	pepository I push this branch to, and other people would
	consider it my fork of the upstream project", but it is hard
	to do the reverse, i.e. a new person who is presented a word
	'fork' to guess that you wanted to refer to the above by
	that word.

I am not saying branch.<name>.push should not exist. Having a finest-grained special case would be an escape hatch you can use when you want to do something unusual.

But it has exactly the same issue as branch.<name>.pushremote; adding it without having the single "all of my pushes go to here, not to 'origin'" would have meant that for N branches you have to set the same thing N times. We fixed it with remote.pushdefault before the series graduated. If you only add branch.<name>.push, then people have to configure it N times, for N branches they want to push out.

Reusing the existing push refspecs was just a suggestion to solve that issue, and I am not married to that particular design. You or Felipe may be able to come up with a better alternative to achieve the same goal and that is perfectly fine. I just wanted to make sure that we do not force the user to repeatedly set the same thing over and over in the common case.

By the way, about "crippling".

I do not think of a reason why you cannot implement that @{f} with the 'single' matching (or its better version you may come up with). If "git push" can figure out where it would push to, you certainly should be able to borrow that same logic to see what tracking branch you are locally using to track the last push result for the current branch in response to @{f} request, no?