From: Eugene Sajine <euguess@gmail.com>
Date: Mon, 31 Jan 2011 22:27:17 GMT
Subject: Re: [1.8.0] make two-argument fetch update remote branches
Message-ID: <AANLkTin2kTW85UC1r_1LUDVLiexcVDvt--9ndnXZ2ARS@mail.gmail.com>
In-Reply-To: <201101312244.10047.trast@student.ethz.ch>

On Mon, Jan 31, 2011 at 4:44 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Proposal:
>
> Running "git fetch origin master" only updates FETCH_HEAD, not
> origin/master, which turns out to be quite confusing for newcomers
> especially after running 'git pull origin master'.
>
> Since the remote branches in some sense reflect the "last known state"
> of the remote, it would make sense to also update them to whatever a
> two-argument fetch got.
>
> Risks:
>
> Scripts might rely on the current behaviour.  The most likely case I
> can think of would be to go along the lines of
>
>  git fetch origin master
>  git rev-list origin/master...FETCH_HEAD | do_something
>
> to avoid relying on reflogs to get the same result.  Seems a bit
> arcane to me though.  Such usage would see the updated state, i.e.,
> process an empty range.
>
> Migration plan:
>
> Add a fetch.updateRemoteNamespace (or so) configuration variable that
> defaults to false.  When enabled, it turns on the auto-updating
> behaviour.
>
> In 1.8.0, flip the default.
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
> --
> 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
>

+1 I really wanted to write this one my self;)

I would disagree with the migration plan though.
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...
In this case FETCH_HEAD will reflect the latest fetch and it doesn't
even need to be removed later on.

just my 2 cents...

Thanks,
Eugene