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

From: Santi Béjar <santi@agolina.net>
Date: Jun 9, 2009, 08:07 UTC
Message-ID: <adf1fd3d0906090107w994de3chb39071e5911a59ae@mail.gmail.com>
In-Reply-To: <adf1fd3d0906090029s2aa7fe19j7b1005997d70b92c@mail.gmail.com>

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

Show 20 quoted lines

> 2009/6/9 Junio C Hamano <gitster@pobox.com>:
>> Santi Béjar <santi@agolina.net> writes:
>>
>>> The only user of get_remote_refs_for_fetch was "git pull --rebase" and
>>> it only wanted the tracking branch to be merge. So, add a simple
>>> function with this new meaning.
>>>
>>> No behavior changes.
>>
>> I am all for code reduction, but after following the original logic that
>> uses remote_refs_for_fetch (which knows about things like "git pull there
>> +refs/heads/master:refs/heads/origin tag v1.6.0" from the command line)
>> that in turn calls canon_refs_list_for_fetch (which returns a list e.g.
>> +refs/heads/master:refs/heads/origin refs/tags/v1.6.0:refs/tags/v1.6.0),
>> and do not quite see how you can casually say "No behaviour changes."
>
> Ups, you are right. But even in you case the only important branch is
> the first, so the only possible change in behavior is:
>
> 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.

Santi