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

["Santi Béjar" <santi@agolina.net>]

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:
>>
>>> 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