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

Eugene Sajine [off-list ref] writes:

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.

With the current system, origin/master is what I _used to_ have before
running this fetch, iow, what I have been looking at as a reference
material while I did my own work so far.  The current "when fetching refs
explicitly, do not touch tracking branches" behaviour guarantees that.

The range above shows what I already knew about the work the other people
did, and what is new on both sides, to help me decide what I want to do
next with the fetched result.  At least that is the workflow the "when
fetching refs explicitly, do not touch tracking branches" behaviour allows
us to support (I am not recommending that the workflow in particular, by
the way).  The next action after seeing what they added is sane may be to
run "git pull" (no arguments), which would fast-forward my view of the
other side to whatever I reviewed this round.