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
> (<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.
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.<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.
Oh, I'm completely against just adding branch.<name>.push as I've
pointed out on the other thread. Even in the part you clipped out, I
clearly stated remote.<name>.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.<name> section, and this might be surprising.
3. If remote.<name>.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.<name>.push idea, and am
tilting towards this now. What do you think?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
