[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [1.8.0] make two-argument fetch update remote branches
From:       Eugene Sajine <euguess () gmail ! com>
Date:       2011-01-31 23:39:19
Message-ID: AANLkTinRo5KxC9OQWyZMnqQP4WHi0sR5qqw6byr4V+3a () mail ! gmail ! com
[Download RAW message or body]

On Mon, Jan 31, 2011 at 6:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Eugene Sajine <euguess@gmail.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]