Re: [PATCHv3 1/4] parse-remote: function to get the tracking branch to be merge

From: Santi Béjar <santi@agolina.net>
Date: Jun 11, 2009, 21:30 UTC
Message-ID: <adf1fd3d0906111430m28ef712axd55942b19505a5b3@mail.gmail.com>
In-Reply-To: <adf1fd3d0906090516l6b1d5ec1rdc78ffffa116b765@mail.gmail.com>

2009/6/9 Santi Béjar <santi@agolina.net>:

Show 32 quoted lines

> 2009/6/9 Santi Béjar <santi@agolina.net>:
>> 2009/6/9 Junio C Hamano <gitster@pobox.com>:
>>> Santi Béjar <santi@agolina.net> writes:
>>>
>>>>> git pull --rebase tags v1.6.0
>>>>
>>>> In fact: git pull --rebase remote tags v1.6.0
>>>>
>>>> But this still works because oldremoteref defaults to defaults_merge.
>>>> So the only behavior change is when a remote branch is
>>>> rebased/retagged, and you have worst problems then. I think noone used
>>>> the rebased functionality in this way, so I don't think it is worth to
>>>> support it. But if someone think it is important I'll do it.
>>>
>>> I personally do not think supporting such a form of input is absolutely
>>> necessary.  Even though technically it might be a regression, if it is so
>>> rare a form, we can simply say "this strange form used to work, but now it
>>> does not; you can use this form instead to do the same thing", and move
>>> on.
>>
>> OK.
>>
>
> At the end it was a little patch to get this corner case working. Here
> it is the patch to squash (I'll send later a proper patch mail, with a
> test).
>
> And this additional sentence in the commit log:
>
> No behavior changes. The new function behaves like the old code used in
> "git pull --rebase".
>

At the end the original code does not handle this case, as it asumes that the rebase ref is a remote commit in refs/remotes/$origin/$ref. So the new code behaves exactly like the old one. I'll send all again with an updated commit message explaining all this.

Santi