Re: Random thoughts on "upstream"

From: Junio C Hamano <gitster@pobox.com>
Date: May 17, 2013, 17:51 UTC
Message-ID: <7vk3mxze8v.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0mLtc8dmMPOcLMez1agF1+ZMUDAUwtwmiKSxOCfyiW0Bw@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 15 quoted lines

> Junio C Hamano wrote:
>
>>         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?

In my original "Random thoughts", I deliberately avoided introducing a new name for the publishing point, because I did not think of a good name myself ("publish" for "what I publish this as?" was what I had in mind, and while it is better than "downstream" which this thing clearly isn't, I do not think it is a great name).

As I said number of times, I am not good at naming, even though I can tell when a proposed name (like "publish") is not a good one X-<.

Matching it with the way to set this per-branch might be a good alternative. If branch.<name>.push is it, then it would mean "@{push}".

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

This is minor, but I am not sure "doesn't require it" part should always stay true in the first place. If you are always forking your 'master' from the upstream 'master' and your 'next' from the upstream 'next', there is no real reason why the user must record an obvious value in branch.master.merge and branch.next.merge variables.

> 2. Setting @{f} with branch --set-fork-to won't operate on the
> branch.<name> section, and this might be surprising.

Hmm, why?

As I said, I do _not_ mean branch.<name>.push must _not_ exist.

Setting it explicitly with --fork-to or whatever option is perfectly fine; the logic to resolve @{f} notation would honor it naturally if you reused the same logic as "git push" decides where to push, no?

> 3. If remote.<name>.push is only going to be used by the Gerrit
> people, @{f} is not going to work anyway.

I do not understand what you mean by this.

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

I think I'd better rephrase what I wanted to say in the message you are responding to.

 * "branch.<name>.push" would be a way to set per-branch push
   destination. There may be other ways to do the same but I do not
   think it is bad and it probably will fall into bikeshedding
   category to attempt to come up with something different for the
   same purpose of setting per-branch destination.

 * There should be a mechanism to allow people _not_ configure it
   per-branch if they do not want to push to randomly custimized
   destinations per-branch (i.e. want to always push $branch to
   refs/heads/$branch, or refs/remotes/satellite/$branch).

So that is what I think.

Having said that I am not sure where your "not overly fond of" comes from, as I do not see a problem with branch.<name>.push. The only problem I may have with the approach would arise _only_ if we make it the sole way to allow people push to different names, forcing people who want to push N branches to configure it N times. Other than that, I think it is an acceptable solution to give per-branch control.