Bad merging with stgit or git

I have a -git tree that generated a really bad result when committed by Linus, generating a really bad history log. My tree is located at: kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git.

I'll try to make a brief from what's happened:

According to him: " ... In particular, commit e338b736f1aee59b757130ffdc778538b7db18d6 is crap, crap, CRAP. It's "Merging Linus tree", but it's not a merge at all: you have just applied the _patch_ to merge the changes in my tree, but you haven't actually told git to do so.

I don't know how/why you did that, but it's totally bogus, and I refuse to pull from that tree. That's a 5000+ line diff, affecting about 180 files! ... "

After a further analysis, it seemed that a merge conflict were badly solved. It is showing this message to Linus:

diff-tree e338b736f1aee59b757130ffdc778538b7db18d6 (from
cb31c70cdf1ac7034bed5f83d543f4888c39888a)
        Author:     Mauro Carvalho Chehab <mchehab@infradead.org>
        AuthorDate: Fri Mar 10 01:30:04 2006 -0300
        Commit:     Mauro Carvalho Chehab <mchehab@infradead.org>
        CommitDate: Fri Mar 10 01:30:04 2006 -0300

            Merging Linus tree

        :100644 100644 be5ae600f5337dbb14daa8d4cace110486e14f79
81bc51369f59a413108fd8b150c3090541ba49f8 M
Documentation/feature-removal-schedule.txt
        :100644 100644 75205391b335f85c9b8a599d0d3b4c0dd1a8b41b
fc99075e0af47f0b73a2ae2dfb7d19920c604dea M
Documentation/kernel-parameters.txt
        :100644 100644 9006063e73691da7b68449955a135f7c9317e2cd
da677f829f7689966bf09aeda6d89fc4b6a876d1 M      arch/alpha/kernel/irq.c

For me, those tree last lines, don't appear. Instead, it just shows, with git-show:

diff-tree e338b736f1aee59b757130ffdc778538b7db18d6 (from
cb31c70cdf1ac7034bed5f83d543f4888c39888a)
Author: Mauro Carvalho Chehab <mchehab@infradead.org>
Date:   Fri Mar 10 01:30:04 2006 -0300

    Merging Linus tree

and a diff file, with:
 179 files changed, 1274 insertions(+), 785 deletions(-)

With git-cat-file, it shows:

$ git-cat-file commit e338b736f1aee59b757130ffdc778538b7db18d6 tree b233a18f740a2883e4863506175f671d821f1e5e parent cb31c70cdf1ac7034bed5f83d543f4888c39888a author Mauro Carvalho Chehab <mchehab@infradead.org> 1141965004 -0300 committer Mauro Carvalho Chehab <mchehab@infradead.org> 1141965004 -0300

Merging Linus tree

It shouldn't have any conflicts here for Linus, since those patches came from his tree.

My current procedure is:

branch origin - Linus tree replica branch work - my stgit main tree branch work-fixes - my stgit tree for bug fixes branch master - patches to current kernel branch devel - patches to next kernel

All patches are generated against work branch, with stgit. Branch work-fixes receives patches by using:

        stg pick <sha>@work

Before commiting to kernel.org, I do:
at origin:
        git pull linus_tree

at master:
        git pull . origin
        git pull . work-fixes

at devel:
        git pull . origin
        git pull . work

My environment is:

Stacked GIT 0.8.1 git version 1.2.4.gfd662 Python version 2.4.2 (#2, Jan 30 2006, 18:33:58) [GCC 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1)]

Any ideas?

On Tue, Mar 21, 2006 at 04:34:13PM -0300, Mauro Carvalho Chehab wrote:

What do you mean by "those patches came from his tree"? If you're actually cherry-picking patches from his tree and applying them to yours, then you're not reproducing the same commits he has--you're just creating new commits that happen to have nearly identical content.

--b.

Em Ter, 2006-03-21 às 14:39 -0500, J. Bruce Fields escreveu:

No, I'm not cherry-picking his patches. 

procedure when solving a conflict, after merging from Linus tree.

detected:

nano <files> git-update-index <files> git commit

Previously (at git 1.1.4), I was doing: nano <files> git commit <files>

git 1.2.4 don't allow this bad commit syntax anymore.

Cheers, Mauro.

Mauro Carvalho Chehab <mchehab@infradead.org> writes:

It is not a bad syntax, and it instead would say "you might have meant to say -i paths...", and if you follow that suggestion to say:

	$ git commit -i this-and-that-file-I-resolved-by-hand

you would commit the cleanly auto-resolved paths _and_ the result of your hand merge result. That is the same traditional behaviour you are used to and is very convenient if you only had a few paths to be hand resolved.

So I suspect there might be something else going on.

On Tue, 21 Mar 2006, Mauro Carvalho Chehab wrote:

Here's a mail that went to linux-kernel to explain some more..

Basically, the problem is that the DVB tree has a perfectly normal commit (_not_ a merge commit), which has the commit message

	"Merging Linus tree"

and is just a patch that apparently merged the changes in my tree at some random state (don't know which, since the commit isn't a merge commit, and doesn't point to the parent it merged from).

I thought it might be a cherry-pick of a merge, or something like that, but the author/committer dates are the same, so that sounds unlikely. However, I could imagine that "stgit" would do something like this if/when it is used to cherry-pick a merge.

Apparently the DVB people also use Mercurial somewhere, so who knows..

		Linus

---
Date: Tue, 21 Mar 2006 11:32:10 -0800 (PST)
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: [PATCH 000/141] V4L/DVB updates part 1

On Tue, 21 Mar 2006, Mauro Carvalho Chehab wrote:

I just did the raw output, so my output was from

	git show --pretty=fuller -r e338b7

which isn't the default, but it's useful if you want to see both committer and author information (and the raw format is just because I wasn't interested in the diff itself, just looking at how many files where changed).

Yeah, we're talking about the same commit.

It's a perfectly good commit. BUT IT IS NOT A MERGE, AND IT IS NOT A DIFF THAT I WANT TO SEE COMING IN FROM AN OUTSIDE TREE!

Basically, in the DVB tree you have absolutely _no_ business in "merging" work from my tree as a patch, especially when the patch you merge has absolutely zero to do with DVB. You just applied a 5000-line patch to the tree, with no merge message other than "Merge from Linus tree", and no attribution about what the f*ck was merged, and why.

THAT is the part I'm unhappy with. The git tree is not "corrupt" from a technical standpoint (it passes fsck). It's "corrupt" because it contains a patch that shouldn't be there, that is mis-attributed, and that incorrectly claims to be a merge when it isn't - it's just a random patch generated against my tree.

		Linus

Dear diary, on Tue, Mar 21, 2006 at 08:34:13PM CET, I got a letter where Mauro Carvalho Chehab <mchehab@infradead.org> said that...

Our IRC hypothesis:

gitweb shows two commits in sequence there,

	11 days ago Mauro Carvalho ...     Merge branch 'origin'
	11 days ago Mauro Carvalho ...     Merging Linus tree

where the "Merge branch 'origin'" commit is a true merge commit, but a rather boring one. There were conflicts during the merge, and according to mchebab they were "resolved" by (incorrectly) doing:

	...edit <files>...
	git-commit <files>

With the old Git version (probably v1.1.4, but I'm not so sure when looking at 1.1.4's git-commit.sh), git-commit would happily do the commit, but wouldn't record the commit as a merge.

On Tue, 21 Mar 2006, Petr Baudis wrote:

I considered that, but as far as I can tell, Mauro is actually using a fairly recent version of "git". How do I know? The second merge (the _real_ one) says

	commit 86d720ef82ca09e75fac06be15da7cbe2721863a
	Merge: e338b73... 8fce4d8...
	Author: Mauro Carvalho Chehab <mchehab@infradead.org>
	Date:   Fri Mar 10 01:32:32 2006 -0300

	    Merge branch 'origin'
    
	    Conflicts:
	    
	        drivers/media/video/saa7134/saa7134-dvb.c
	    nothing to commit

and that "Conflicts:" thing from git is actually reasonably recent (it's from end of January), and almost certainly doesn't exist in v1.1.4 (I don't think it exists in any 1.1.x version).

So it's 1.2.0 or newer (or some random build, of course).

And I _hope_ that no git that recent will commit a merge in progress. 

However, it does look like the 

	case "$all,$also" in
	,t)

case doesn't check for MERGE_HEAD. That could be the bug. Junio?

		Linus

Linus Torvalds <torvalds@osdl.org> writes:

Not even 1.1 series for that matter, no.

I do not think so.  

"Also" (aka -i) means "run update-index for these paths for me first, and commit them alongside with what I (or merge) have already updated in the index".