Re: Octopus merge: unique (?) to git, but is it useful?

Linus Torvalds [off-list ref] writes:

Junio: see kernel commits a733a5da9 and 52b097fff89, done as lately as 
February of this year. We shouldn't allow that kind of thing,...

Well, we even allow fast-forwrad to be recorded as a true merge if the
user asks these days.

And the thing is, that "a733a5da9" commit has a smoking-gun evidence that
a nonsense is asked by the committer.

    commit a733a5da97b238e3e3167d3d0aee8fe1e8d04e97
    Merge: 299cfe3... 299cfe3... 9e52797...
    Author:     Len Brown [off-list ref]
    AuthorDate: Thu Feb 7 03:38:22 2008 -0500
    Commit:     Len Brown [off-list ref]
    CommitDate: Thu Feb 7 03:38:22 2008 -0500

        Merge branches 'release' and 'fluff' into release

        Conflicts:

            drivers/acpi/scan.c
            include/linux/acpi.h

        Signed-off-by: Len Brown [off-list ref]

"Merge branches 'RELEASE' and 'fluff' into RELEASE"?  That happens if you
are _on_ release branch and say "git merge release fluff".

Having said that, I think what is happening is that the final set of
"other parents" is computed inside git-merge out of MERGE_HEAD and that is
usually what is recorded in the resulting merge, but if the merge results
in a conflict with manual resolution, that information is not given to the
final "git commit".  The resulting commit records the parents out of HEAD
and MERGE_HEAD.  I do not think this part has changed from scripted
version of git-commit.

On Mon, 2 Jun 2008, Junio C Hamano wrote:

"Merge branches 'RELEASE' and 'fluff' into RELEASE"?  That happens if you
are _on_ release branch and say "git merge release fluff".

Right. But git shouldn't do duplicate parents. I agree it's a mis-use of 
git merge, but either we should have errored out or we should have pruned 
the parents.

Yes, the end result is "tecnically correct", but it's not optimal.

		Linus

On Tue, Jun 03, 2008 at 07:40:21AM -0700, Linus Torvalds [off-list ref] wrote:

Right. But git shouldn't do duplicate parents. I agree it's a mis-use of 
git merge, but either we should have errored out or we should have pruned 
the parents.

Yes, the end result is "tecnically correct", but it's not optimal.

I think the current git-merge.sh already handles this: 6ea23343
introduced the usage of git-show-branch --independent to filter out
duplicated parents.