From: Ramkumar Ramachandra Date: Fri, 17 May 2013 17:01:13 GMT Subject: Re: Random thoughts on "upstream" Message-ID: In-Reply-To: <7vk3mx1rox.fsf@alter.siamese.dyndns.org> Junio C Hamano wrote: > 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 > (, ))? 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. Yes. > 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. GitHub is an overwhelmingly popular service, and many end-users are used to clicking on the "Fork" button on various projects to contribute. Here, "fork" is short for "my fork". Do you have a better name in mind? > But it has exactly the same issue as branch..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..push, > then people have to configure it N times, for N branches they want > to push out. Oh, I'm completely against just adding branch..push as I've pointed out on the other thread. Even in the part you clipped out, I clearly stated remote..push above a branch-specific thing in the priorities. > 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. Ofcourse. > 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? Ofcourse, I'm not saying it's not possible. 1. Getting @{f} requires extra computation, and that might be ugly/ undesirable/ surprising considering how @{u} doesn't require it. 2. Setting @{f} with branch --set-fork-to won't operate on the branch. section, and this might be surprising. 3. If remote..push is only going to be used by the Gerrit people, @{f} is not going to work anyway. These issues aren't deal breakers, but are certainly worth mentioning. Frankly, I'm not overtly fond of the branch..push idea, and am tilting towards this now. What do you think?