Re: [1.8.0] make two-argument fetch update remote branches

On Mon, Jan 31, 2011 at 6:06 PM, Junio C Hamano [off-list ref] wrote:

Eugene Sajine [off-list ref] writes:

quoted

IMHO there is no need to introduce the variable. If it will start
update both FETCH_HEAD and the remote-tracking branches since 1.8 it
will not break any code, because it is added functionality...

Then you didn't understand the risks section, did you?  Thomas clearly
illustrated with an example where the script _expects_ origin/master to
stay the same after "git fetch origin master".

I did understand what Thomas illustrated. I'm just thinking that the
range origin/master...FETCH_HEAD seems to be useful but in fact is
pretty useless, because you cannot guarantee the state of the
origin/master _before_ the fetch and therefore you cannot rely on the
results of range selections involving it.
By "guaranteeing the state" i mean that because of the current
implementation origin/master doesn't always mean/reflect the same
thing: it might be some _old_ and outdated push or it might be some
new state of the remote branch which are IMHO completely different
semantics.

That's exactly why it seems to me that it is important to always
update remote-tracking branches upon any related network operation. So
remote-tracking branch always represents the _same_ thing - the latest
state of the remote branch that you interacted with.


Thanks,
Eugene