Bad merging with stgit or git

Bad merging with stgit or git

[Mauro Carvalho Chehab]

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?

Re: Bad merging with stgit or git

[J. Bruce Fields]

On Tue, Mar 21, 2006 at 04:34:13PM -0300, Mauro Carvalho Chehab wrote:
> It shouldn't have any conflicts here for Linus, since those patches came
> from his tree.

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.

Re: Bad merging with stgit or git

[Linus Torvalds]

On Tue, 21 Mar 2006, Mauro Carvalho Chehab wrote:
>
> 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.

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:
> 
> Weird, I can't see all those stuff here. It shows something like
> (running from master copy at kernel.org):

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).

> So, after the merging message, I have a normal diff with:
> 
>  179 files changed, 1274 insertions(+), 785 deletions(-)

Yeah, we're talking about the same commit.

> Seeming all perfect from my knowledge about git.

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

Re: Bad merging with stgit or git

[Petr Baudis]

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

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.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.

Re: Bad merging with stgit or git

[Mauro Carvalho Chehab]

Em Ter, 2006-03-21 às 14:39 -0500, J. Bruce Fields escreveu:
> On Tue, Mar 21, 2006 at 04:34:13PM -0300, Mauro Carvalho Chehab wrote:
> > It shouldn't have any conflicts here for Linus, since those patches came
> > from his tree.
> 
> 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.
No, I'm not cherry-picking his patches. 

>From the discussions on git IRC, I think it may be caused by a bad
procedure when solving a conflict, after merging from Linus tree.

>From what I'm understanding now, I should do, when a conflict is
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.

> 
> --b.
Cheers, 
Mauro.

Re: Bad merging with stgit or git

[Linus Torvalds]

On Tue, 21 Mar 2006, Petr Baudis wrote:
> 
> 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.

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

Re: Bad merging with stgit or git

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

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

Not even 1.1 series for that matter, no.

> However, it does look like the 
>
> 	case "$all,$also" in
> 	,t)
>
> case doesn't check for MERGE_HEAD. That could be the bug. Junio?

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".

Re: Bad merging with stgit or git

[Junio C Hamano]

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

>From what I'm understanding now, I should do, when a conflict is
> 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.

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.