2009/6/9 Santi Béjar <santi@xxxxxxxxxxx>: > 2009/6/9 Junio C Hamano <gitster@xxxxxxxxx>: >> Santi Béjar <santi@xxxxxxxxxxx> 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 -- 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