"Jan Hudec" [off-list ref] writes:
- During the testing I found a problem, but it may have already
existed on master before the merge.
- Therefore I needed to return to clean master, test it and return
to the merge. So I thought I'd commit the merge to a temporary
branch, test master again and merge the temporary to master if
the problem is not from the merge. So I did:
$ git checkout -b temp
$ git commit
OOPS! It forgot it was a merge.
I think it was an oversight by the author of 91dcdfd (Make "git checkout"
create new branches on demand, 2005-07-11) who forgot that he also did
ef0bfa2 (Remove MERGE_HEAD in "git checkout/reset", 2005-06-21). The
rationale for the removal of MERGE_HEAD from the earlier commit is:
[this command] will end up resetting the index to some specific
head, and any unresolved merge will be forgotten [hence there is no
point recording the result as a merge].
but when used with -b no such "resetting of the index" happens.
Having said that, changing it not to remove MERGE_HEAD and MERGE_MSG is
probably not sufficient, as MERGE_MSG would likely to already record to
which branch you are recording the merge (I didn't check, though).
On Thu, Nov 18, 2010 at 10:39:31 -0800, Junio C Hamano wrote:
"Jan Hudec" [off-list ref] writes:
quoted
So I did:
$ git checkout -b temp
$ git commit
OOPS! It forgot it was a merge.
I think it was an oversight by the author of 91dcdfd (Make "git checkout"
create new branches on demand, 2005-07-11) who forgot that he also did
ef0bfa2 (Remove MERGE_HEAD in "git checkout/reset", 2005-06-21). The
rationale for the removal of MERGE_HEAD from the earlier commit is:
[this command] will end up resetting the index to some specific
head, and any unresolved merge will be forgotten [hence there is no
point recording the result as a merge].
but when used with -b no such "resetting of the index" happens.
Having said that, changing it not to remove MERGE_HEAD and MERGE_MSG is
probably not sufficient, as MERGE_MSG would likely to already record to
which branch you are recording the merge (I didn't check, though).
I believe it indeed does. However since it's now just a template for the
commit message, it can be fixed up by the user. If he actually wants to, that
is.
In my case, I only needed to stash the changes, so I could switch back to
'master' (left merge parent) to test the bug I was seeing was already there
and than I merged the temporary branch to 'master' (which was fast forward).
So the message saying I merged to 'master' was actually appropriate even when
I was commiting to some other ref.
--
Jan 'Bulb' Hudec [off-list ref]
On Thu, Nov 18, 2010 at 10:39:31AM -0800, Junio C Hamano wrote:
I think it was an oversight by the author of 91dcdfd (Make "git checkout"
create new branches on demand, 2005-07-11) who forgot that he also did
ef0bfa2 (Remove MERGE_HEAD in "git checkout/reset", 2005-06-21). The
rationale for the removal of MERGE_HEAD from the earlier commit is:
[this command] will end up resetting the index to some specific
head, and any unresolved merge will be forgotten [hence there is no
point recording the result as a merge].
but when used with -b no such "resetting of the index" happens.
It is not necessarily about "-b" is it? It is about moving to a
different commit. So I would think that on branch "master":
# should clear MERGE_HEAD
git checkout foo
# should not clear MERGE_HEAD; it's a no-op, and we have in the past
# encouraged people to run this to see the ahead/behind count
git checkout
# or
git checkout master
# should clear MERGE_HEAD; we are moving to a new commit
git checkout -b foo some_commit
# should not clear MERGE_HEAD; this is Jan's case
git checkout -b foo
# or
git checkout -b foo master
-Peff