On Mon, Jan 31, 2011 at 4:44 PM, Thomas Rast <trast@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> 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
--
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