'git commit' duplicates parents?

I just checked in a change with 'git commit' (no arguments).  Two 
strange things occurred:

1) git-whatchanged does not list the change at all.  However,
	a) I verified that my change is indeed top-of-tree
	b) git-changes-script (attached) does show the change

2) git-changes-script shows the parents in a readable fashion, and it 
shows two duplicate parent entries.  In contrast, other changes do not 
have two parents:

my change:

commit 4864989199fa62c7044be2258550ddc561411ab6

		^^^ top of tree aka .git/HEAD

tree b40996c7a0a5446875aa3664045af7e377451bf6
parent 7df551254add79a445d2e47e8f849cef8fee6e38
parent 7df551254add79a445d2e47e8f849cef8fee6e38
author Jeff Garzik [off-list ref] Sun, 19 Jun 2005 20:06:28 -0400
committer Jeff Garzik [off-list ref] Sun, 19 Jun 2005 20:06:28 -0400

fc4/fc:  fix warnings/errors caused by recent changes

a random change not committed by 'git commit':

commit 7df551254add79a445d2e47e8f849cef8fee6e38
tree 468a43ac3f94b9bf8618b102a7d609e29d3900f5
parent f7d7fc0322c1770fe7ee836ca2732c2f88e2e1a4
author David S. Miller [off-list ref] Sun, 19 Jun 2005 13:01:10 -0700
committer David S. Miller [off-list ref] Sun, 19 Jun 2005 13:01:10 -0700

[TCP]: Fix sysctl_tcp_low_latency

When enabled, this should disable UCOPY prequeue'ing altogether,
but it does not due to a missing test.

Signed-off-by: David S. Miller <davem@davemloft.net>

Jeff Garzik wrote:

I just checked in a change with 'git commit' (no arguments).  Two 
strange things occurred:

FWIW you can see the problem yourself at

'fc4-fix' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git

(just one change checked in, the change referenced in the previous email)

On Sun, 19 Jun 2005, Jeff Garzik wrote:

I just checked in a change with 'git commit' (no arguments).  Two 
strange things occurred:

1) git-whatchanged does not list the change at all.  However,
	a) I verified that my change is indeed top-of-tree
	b) git-changes-script (attached) does show the change

Your commit is a merge. A corrupted one.

2) git-changes-script shows the parents in a readable fashion, and it 
shows two duplicate parent entries.  In contrast, other changes do not 
have two parents:

my change:

quoted

commit 4864989199fa62c7044be2258550ddc561411ab6

		^^^ top of tree aka .git/HEAD

quoted

tree b40996c7a0a5446875aa3664045af7e377451bf6
parent 7df551254add79a445d2e47e8f849cef8fee6e38
parent 7df551254add79a445d2e47e8f849cef8fee6e38

Notice: two times the same head.

You had a MERGE_HEAD in your tree, and "git commit" warned you about it in 
big bold letters and told you what to do, but you ignored it.

"git commit" said:

                echo "#"
                echo "# It looks like your may be committing a MERGE."
                echo "# If this is not correct, please remove the file"
                echo "# $GIT_DIR/MERGE_HEAD"
                echo "# and try again"
                echo "#"

and if you had just done as it asked you, you'd have been ok.

As to why you had a .git/MERGE_HEAD in your tree, it's probably because 
your merge scripts haven't kept up with mine.

		Linus

Linus Torvalds wrote:

As to why you had a .git/MERGE_HEAD in your tree, it's probably because 
your merge scripts haven't kept up with mine.

Nope, I use vanilla latest ones.  FWIW my setup is 100% vanilla git plus 
two small scripts, 'git-switch-tree' and 'git-new-branch', which switch 
around .git/HEAD.

Doing some experimenting, it seems that git-pull-script does not remove 
MERGE_HEAD and ORIG_HEAD after its done.

This is reproducible by updating vanilla linux-2.6.git using vanilla 
git-pull-script.  Just a standard update-to-latest-kernel, with no 
conflicts/merges/etc.

	Jeff

On Sun, 19 Jun 2005, Linus Torvalds wrote:

Your commit is a merge. A corrupted one.

Btw, if possibly, you should just undo it. It's "valid" in the sense that
having the same parent duplicated will just be considered to be a merge by
a paritcularly strange person, but it's definitely not good practice, and
since it _is_ technically a merge, programs that avoid showing merges
(like "git-whatchanged" - because it doesn't know what it should show as 
the "difference") won't show it.

Other programs, like "git-diff-tree -m", which show _all_ sides of a 
merge, will show the diff twice (because it shows the diff against all 
parents). Which is also why you see it twice in your git-changes-script.

Again, "git commit" _did_ warn about this, I'm sure, but I actually see 
why that stupid MERGE_HEAD file was there - a null merge won't remove a 
stale MERGE_HEAD, so it's probably because you did a "git pull" that was a 
trivial merge, and that would have left that turd around..

		Linus

Linus Torvalds wrote:

Btw, if possibly, you should just undo it. It's "valid" in the sense that

Any crap like this, I undo it manually (cat previous head to .git/HEAD)

Again, "git commit" _did_ warn about this, I'm sure, but I actually see 
why that stupid MERGE_HEAD file was there - a null merge won't remove a 
stale MERGE_HEAD, so it's probably because you did a "git pull" that was a 
trivial merge, and that would have left that turd around..

Probably PEBCAK...  my missing the big "MERGE_HEAD exists" warning 
caused the problem, it sounds like.

I simply assumed that the vanilla git scripts would clean up after 
themselves :)

	Jeff

On Sun, 19 Jun 2005, Jeff Garzik wrote:

I simply assumed that the vanilla git scripts would clean up after 
themselves :)

Hey, they definitely should. I've pushed out the fixes so far (just pushed
out the ".cmitmsg/.editmsg" cleanup).

Keep the complaints coming when something doesn't work the way it should.  
I'll continue to try to blame your incompetence as much as I humanly can,
but hey, some of it is occasionally mine too... ;(

		Linus

Linus Torvalds wrote:

Keep the complaints coming when something doesn't work the way it should.  
I'll continue to try to blame your incompetence as much as I humanly can,
but hey, some of it is occasionally mine too... ;(

Well, since it's obviously complaint time :-)

git-resolve-script still seems a bit too eager to write MERGE_HEAD and 
ORIG_HEAD - they only make sense if there's actually been any merging 
done, don't they?

Patch below shows what I mean.

/dan

---

[PATCH] Make git-resolve-script less eager to write MERGE_HEAD

MERGE_HEAD and ORIG_HEAD should only be written if there's actually
been any merging done.

Signed-off-by: Dan Holmsand <redacted>

On Mon, 20 Jun 2005, Dan Holmsand wrote:

git-resolve-script still seems a bit too eager to write MERGE_HEAD and 
ORIG_HEAD - they only make sense if there's actually been any merging 
done, don't they?

Patch below shows what I mean.

I considered this, but decided that MERGE_HEAD is potentially very useful
for some of the other failure exits. There's a few "exit 1"'s in there,
for example when the "git-read-tree -m"  fails because of a dirty
workspace.

Of course, you can always re-do the merge completely (and maybe that's 
what people end up doing), but at least in theory you can fix it up and 
just re-resolve. But in order to do that, you need to know what the 
MERGE_HEAD was...

So I'm not sure what the right answer is, which is why my fix was the 
minimally invasive one that only removes the heads on success..

		Linus

Linus Torvalds wrote:

On Mon, 20 Jun 2005, Dan Holmsand wrote:

quoted

git-resolve-script still seems a bit too eager to write MERGE_HEAD and 
ORIG_HEAD - they only make sense if there's actually been any merging 
done, don't they?

Patch below shows what I mean.

I considered this, but decided that MERGE_HEAD is potentially very useful
for some of the other failure exits. There's a few "exit 1"'s in there,
for example when the "git-read-tree -m"  fails because of a dirty
workspace.

Yeah, but that was exactly what I was after...

As far as I understand it, the git-read-tree -u -m doesn't actually do
anything when the workspace is dirty - so there's actually no merging 
going on, right?

If you react to the dirty-workspace-warnings in such a failed merge by 
"git commit-ing" (and not noting the MERGE_HEAD warning, which has been 
known to happen), you'll end up with an unwanted parent in the commit.

Or am I just being stupid :-?

/dan

On Mon, 20 Jun 2005, Dan Holmsand wrote:

Yeah, but that was exactly what I was after...

As far as I understand it, the git-read-tree -u -m doesn't actually do
anything when the workspace is dirty - so there's actually no merging 
going on, right?

No, but you can trivially do so by hand afterwards.

For example, git-read-tree -u -m will complain and say "file xyz is 
dirty, cannot merge" (or something), and what you might decide to do is 
just

	git-checkout-cache -f -u xyz
	git resolve $(cat .git/HEAD) $(cat .git/MERGE_HEAD) "..."

and note how you needed to know what the merge head was in order to do 
this.

[ Side note: I should make "git-resolve-script" run "git-rev-parse" on its
  arguments, so that it would expand HEAD and MERGE_HEAD on its own. Maybe 
  somebody who is interested in this script might want to do that? Hint 
  hint. ]

Note how we could make both of us happy by saving that temporary 
MERGE_HEAD information somewhere _else_ instead. Maybe the answer is to 
only use "MERGE_HEAD" for the "merge manually" case, and use something 
else for the "this was the merge you tried to do last" case?

		Linus

Linus Torvalds wrote:

[ Side note: I should make "git-resolve-script" run "git-rev-parse" on its
  arguments, so that it would expand HEAD and MERGE_HEAD on its own. Maybe 
  somebody who is interested in this script might want to do that? Hint 
  hint. ]

Got it. Included below.

Note how we could make both of us happy by saving that temporary 
MERGE_HEAD information somewhere _else_ instead. Maybe the answer is to 
only use "MERGE_HEAD" for the "merge manually" case, and use something 
else for the "this was the merge you tried to do last" case?

I like the "everybody happy" idea...

How about "LAST_MERGE"? And something like this?

/dan

---

[PATCH] git-resolve-script: Add LAST_MERGE and use git-rev-parse

Make git-resolve-script only write MERGE_HEAD if a merge actually
occurred. All merge failures leave ORIG_HEAD and LAST_MERGE
behind (instead of ORIG_HEAD and MERGE_HEAD).

Use git-rev-parse to expand arguments (and check for bad ones).

Signed-off-by: Dan Holmsand <redacted>