Re: Random thoughts on "upstream"

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: May 17, 2013, 17:01 UTC
Message-ID: <CALkWK0mLtc8dmMPOcLMez1agF1+ZMUDAUwtwmiKSxOCfyiW0Bw@mail.gmail.com>
In-Reply-To: <7vk3mx1rox.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 7 quoted lines

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

Show 8 quoted lines

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

Show 7 quoted lines

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

Show 6 quoted lines

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

Show 6 quoted lines

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