Re: [1.8.0] make two-argument fetch update remote branches
- From
- Eugene Sajine <euguess@gmail.com>
- Date
- Jan 31, 2011, 22:27 UTC
- 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:
Show 38 quoted lines
> 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