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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Eugene Sajine <euguess@xxxxxxxxx> 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.
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]