On Thu, May 16, 2013 at 8:59 PM, Felipe Contreras
<felipe.contreras@xxxxxxxxx> wrote:
> On Thu, May 16, 2013 at 8:31 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> Junio C Hamano <gitster@xxxxxxxxx> writes:
>>
>>> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>>>
>>>> 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'.
>>
>> Actually, I suspect that you shouldn't even need to do that
>> pros-and-cons analysis, because the 'single' thing should cover as a
>> natural extension of the existing infrastructure. You should only
>> need to have something like this:
>>
>> [remote "there"]
>> url = ... were you push ...
>> push = refs/heads/frotz:refs/heads/topics/frotz-for-juno
>> push = refs/heads/*:refs/heads/topics/*
>>
>> Without the 'single', your 'frotz' will be pushed to update
>> heads/topics/frotz-for-juno, not heads/topics/frotz, because the
>> exact refspec match will prevent it from matched twice by the
>> wildcarded one. The imagined 'single' mode would just limit the
>> push to the current branch, so it would end up pushing to the branch
>> you want to update, without sending an extra copy to the same name.
>
> And would 'git branch --set-downstream-to github/frotz-for-juno' do
> that? If not it's basically useless for 99% of the users who never
> fiddle with push refspecs.
And 'git branch -vv' would not show that either. Nor can the user do
'@{downstream}'.
--
Felipe Contreras
--
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