Re: who's on first? - following first parent and merge-management

Am 3/9/2012 13:05, schrieb Holger Hellmuth:

On 08.03.2012 18:30, Junio C Hamano wrote:

quoted

Johannes Sixt[off-list ref]  writes:

quoted

To avoid the situation,...
This would not be necessary if the order of the merge parents could be
specified, e.g.:

    # on topic
    git merge --into master

I think the underlying mechanism needed to implement the above
shares a lot with what Jeff called "crazy idea", but where you would
want to be after such a merge may be different in these two cases.

I don't think there is much question that you should still be in the same
branch. Not because you necessarily want to be in that branch. But because
it would be surprising if git-merge changed your branch sometimes and most
times not.

I don't think that it is so clear-cut. And for this reason, I would even
go as far as to suggest that you should end up with a detached HEAD.

Before the merge we have this situation:

--o--o--o--o      <- master
   \
    o--o--o--X    <- topic

The result of 'git merge --into master' must advance branch master by the
merge commit (I think there is no doubt about this):

--o--o--o--o---M  <- master
   \          /
    o--o--o--X    <- topic

Also, the index and worktree must match M (no doubt, either, IMO). But
what does HEAD refer to? I see three possibilities:

1. master; as you say, this may be surprising if we were on topic before
the branch.

2. topic; but then the index would be dirty because it does not match X.

3. M, i.e. a detached HEAD; this is just a compromise and a fat warning at
the end of the merge output would be necessary that instructs the user to
checkout a suitable branch.

Now that I have tossed around these ideas, there's another caveat: What if
the merge fails due to a conflict? After the conflicts were resolved, 'git
commit' is needed to complete the merge. But this would create the commit
where HEAD points to. IOW, we have to chose option 1 so that the merge
commit advances master.

Would this be less surprising if the option were named --checkout-into?

-- Hannes