On Mon, Jan 31, 2011 at 6:06 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Eugene Sajine <euguess@xxxxxxxxx> writes: > >> 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 -- 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