Re: FETCH_HEAD question

[Jay Soffian <jaysoffian@gmail.com>]

On Tue, Feb 17, 2009 at 3:35 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Now to something totally useless.
>
> After reading the builtin-merge.c and original git-merge.sh (now in
> contrib/examples) script, I think it could have done something entirely
> different.
>
> It could have done this instead.
>
>        sed -e '/       not-for-merge   /d'
>
> to learn the commits and their human-readable origins, and it could have
> tried to reproduce what "git pull" did when it invoked git-merge using
> that information.  Then you could use this workflow:
>
>        $ git pull <possibly with arguments>
>        ... oops, conflicted and is very messy.
>        ... I tried to resolve, but failed and made the mess even worse.
>        ... Let's start over.
>        $ git reset --hard
>        ... FETCH_HEAD knows which refs are for merging
>        $ git merge FETCH_HEAD
>
> That is, no matter what the arguments were for the initial "git pull",
> what should be merged is recorded in FETCH_HEAD, and that is how you can
> retry the merge without refetching over the network.
>
> But such a change makes FETCH_HEAD different from what it traditionally
> meant, and does that only to "git merge", making the result very
> inconsistent.  For example, "git log ..FETCH_HEAD" will still use the
> object name on the first line, and it won't be a way to convince yourself
> that the changes are sensible and it is Ok to run "git merge FETCH_HEAD"
> anymore.  So I do not think such a change will be an improvement.

Unless dwim_ref() is updated to handle FETCH_HEAD specially, and
return not the first SHA1, but the one not marked "not-for-merge".
Then the UI would at least be consistent, but this would not be
backward compatible.

j.