Re: Random thoughts on "upstream"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:

> On Thu, May 16, 2013 at 12:55 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
>> The value "upstream" for push.default does not make sense in the
>> context of a triangular workflow, as you may well base your work on
>> 'master' from the upstream, which is a branch with a very generic
>> purpose (e.g. "to advance the state of the overall project"), but
>> your work may have a more specific purpose (e.g. "to improve frotz
>> feature") that deserves to be on a branch named after that specific
>> purpose in the repository you publish your work on.  That is, after
>> working on your 'frotz' branch this way:
>>
>>     git checkout -t -b frotz origin/master
>>     work work work, commit commit commit
>
> If the user has branch.autosetupmerge=always, that's not correct; even doing:
>
> % git checkout -b frotz origin/master
>
> Would setup the upstream. And I believe for v2.0 we do want
> branch.autosetupmerge=always, but we might not want to always override
> the push location.
>
>> Now I have a curious value "single" in the above configuration that
>> is not understood by current Git.  It is to trigger a new rule to
>> modify the way remote.publish.push refspec is used:
>>
>>     When on branch 'frotz', where pushremote_get() would return
>>     'publish', find where refs/heads/frotz would be pushed with the
>>     refspec for that remote (i.e. refs/heads/*:refs/heads/topics/*
>>     maps refs/heads/frotz to refs/heads/topics/frotz) and push only
>>     that, i.e. update refs/heads/topics/frotz over there with the
>>     tip of 'frotz' we are pushing.
>>
>> That may be a solution for those who do not find 'current' good
>> enough.
>
> What happens if I want to push to 'refs/heads/topics/frotz-for-juno'?

You would weigh pros-and-cons of supporting such a "single branch
only" special case, and add a branch level override, and if the
benefit outweighs the cost of complexity, design and implement it.

The push.default setting is to make sure we have a simple mechanism
to cover more common cases, and my suspicion is what 'current' gives
us is already there without the need for 'single'.
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]