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

On 09.03.2012 13:29, Johannes Sixt wrote:

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

quoted

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:

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.