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

[Holger Hellmuth <hellmuth@ira.uka.de>]

On 09.03.2012 13:29, Johannes Sixt wrote:
> 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:

I see we have different ideas. I envisioned --into to be the equivalent of
git checkout master
git merge topic
git checkout topic

and in that case index and worktree would be topic naturally.

But your caveat below would be even more problematic in this case.

> 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?

Don't think so. It would make it clear where you end up but it would 
muddle/hide the original purpose of the parameter. "git merge --into 
xxx" sounds like a real sentence (Larry Wall would approve ;-).

Guess we would have to rely on the documentation to make it clear that a 
branch switch happens. And a message "Changing to branch xxx" on STDOUT 
wouldn't hurt either.