Eugene Sajine [off-list ref] writes:
quoted
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: [off-list ref]
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.
quoted
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: [off-list ref]
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.
Thank you, Junio, for the update.
Eugene
On Tue, Jun 29, 2010 at 12:27:09PM -0700, Junio C Hamano wrote:
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 am probably the best person to take another look at it (though I would
be fine if somebody else wants to volunteer).
Right now I am in the process of switching day jobs and doing an
inter-state move, so it will probably be a month before I have a lot of
git time.
-Peff