Re: origin/branchname and tracking branch pointing to different commits?

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 29, 2010, 19:27 UTC
Message-ID: <7vocet8ws2.fsf@alter.siamese.dyndns.org>
In-Reply-To: <AANLkTik7bleuzqnMWMJoWljQ5zD0YbwBsFjZT5IzkV0q@mail.gmail.com>

Eugene Sajine <euguess@gmail.com> writes:

Show 11 quoted lines

>> This was discussed a while back:
>>
>>  http://thread.gmane.org/gmane.comp.version-control.git/127163
>>
>> and I even posted a patch, but never followed up (I think mostly just
>> due to being busy).. There is some concern about unexpected ref updates,
>> though.
>
> Jeff, Junio
>
> Could you, please, advise if there is any resolution on the patch?

I do agree with Jeff that what his patch tried to do back in August last year was introducing backward compatibility and potentially breaking workflows of existing users by updating refs in an unexpected ways.

However, as I discussed in

    Subject: Re: origin/branchname and tracking branch pointing to different  commits?
    Date: Thu, 07 Jan 2010 16:32:09 -0800
    Message-ID: <7v7hrtzbau.fsf@alter.siamese.dyndns.org>

I have a slight suspicion that such an "unexpected ref update" is not a big issue anymore. So in principle, I think it is fine to change the behaviour of "git fetch $there $these_explicit_refs" to additionally follow the configured remote tracking ref globbing patterns.

Because

 (1) the old patch was never tested in a production context (I don't think
     it even hit 'pu');

 (2) I offhand do not know how much the codebase changed in the area that
     would affect the assumptions the patch made back then; and

 (3) we will be in feature freeze for 1.7.2 anyway;

I would rather not be the one who is forward-porting the patch myself if I can avoid it, however.

I could queue a version of the patch (with updates if necessary) to 'pu', but not much more than that right now.