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

[Johannes Sixt <j.sixt@viscovery.net>]

Am 3/9/2012 13:05, schrieb Holger Hellmuth:
> On 08.03.2012 18:30, Junio C Hamano wrote:
>> Johannes Sixt<j.sixt@viscovery.net>  writes:
>>> 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