Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html