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

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

[Jakub Narebski]

I think that octopus merge (merge with more than two parents/legs) is 
feature which is unique to git (isn't it?).  Do you remember perhaps 
why it was introduced?  What does it give, beside making it difficult 
to convert git repositories using this feature to others SCMs, for 
example for comparison:
  http://vcscompare.blogspot.com/2008/05/meet-candidates.html

TIA
-- 
Jakub Narebski
Poland

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

[Linus Torvalds]

On Tue, 3 Jun 2008, Jakub Narebski wrote:
>
> I think that octopus merge (merge with more than two parents/legs) is 
> feature which is unique to git (isn't it?).  Do you remember perhaps 
> why it was introduced?

Well, mainly because the data structures supported the notion naturally.

Once you have 0, 1 or 2 parents, the logical progression is "many". 

> What does it give, beside making it difficult 
> to convert git repositories using this feature to others SCMs

Actually, it's trivial to convert to other SCM's, although I guess the 
conversion tools haven't really tried. You can always turn it into a 
series of multiple merges. Yes, you lose information, but it's not like 
you lose a huge amount.

As to how useful it is.. We don't have a lot of them in the kernel, but I 
do have to say that the ones we have generally tend to make perfect sense. 

To see just octopus merges, do

	git rev-list --parents HEAD |
		grep '.* .* .* ' |
		git diff-tree --stdin --pretty --always -S |
		less -S

but a couple of them are actually fake (same parent listed twice), due to 
a confluence of (a) historically bad "git merge" semantics and (b) a bug 
that made it not notice. In fact, that bug seems to have re-appeared, now 
that I look at it!

Junio: see kernel commits a733a5da9 and 52b097fff89, done as lately as 
February of this year. We shouldn't allow that kind of thing, and in git 
we have commits b389237ae and 6ea23343ce that were both about those kinds 
of mis-uses.

That said, most of those octopus merges look fine and actually give a 
nicer view of history. Of course, Len has been known to over-do it a bit ;)

		Linus

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

[Daniel Villeneuve]

Jakub Narebski wrote:
> I think that octopus merge (merge with more than two parents/legs) is 
> feature which is unique to git (isn't it?).  
PRCS (http://prcs.sourceforge.net) allows to merge multiple branches 
into the
current working directory, making the eventually committed version have 
multiple
parents.
--
Daniel Villeneuve

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

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> 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 <len.brown@intel.com>
    AuthorDate: Thu Feb 7 03:38:22 2008 -0500
    Commit:     Len Brown <len.brown@intel.com>
    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 <len.brown@intel.com>

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

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

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> Actually, it's trivial to convert to other SCM's, although I guess the 
> conversion tools haven't really tried. You can always turn it into a 
> series of multiple merges. Yes, you lose information, but it's not like 
> you lose a huge amount.

One thing to worry about is what tree object you would give to each of
these "artificially split" merge commits, though.

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

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

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

Sorry, my thinko.

The scripted version obviously used commit-tree to omit the duplicated
parent.  Perhaps we can do something like this.

-- >8 --
commit: drop duplicated parents

The scripted version of git-commit internally used git-commit-tree which
omitted duplicated parents given from the command line.  This prevented a
nonsensical octopus merge from getting created even when you said "git
merge A B" while you are already on branch A.

However, when git-commit was rewritten in C, this sanity check was lost.
This resurrects it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin-commit.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/builtin-commit.c b/builtin-commit.c
index b294c1f..1d8d208 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -883,10 +883,19 @@ static void add_parent(struct strbuf *sb, const unsigned char *sha1)
 {
 	struct object *obj = parse_object(sha1);
 	const char *parent = sha1_to_hex(sha1);
+	const char *cp;
+
 	if (!obj)
 		die("Unable to find commit parent %s", parent);
 	if (obj->type != OBJ_COMMIT)
 		die("Parent %s isn't a proper commit", parent);
+	cp = strstr(sb->buf, parent);
+	if (cp &&
+	    sb->buf + 8 <= cp && !memcmp(cp - 8, "\nparent ", 8) &&
+	    cp[40] == '\n') {
+		error("duplicate parent %s ignored", parent);
+		return;
+	}
 	strbuf_addf(sb, "parent %s\n", parent);
 }
 

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

[Johannes Schindelin]

Hi,

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

> diff --git a/builtin-commit.c b/builtin-commit.c
> index b294c1f..1d8d208 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -883,10 +883,19 @@ static void add_parent(struct strbuf *sb, const unsigned char *sha1)
>  {
>  	struct object *obj = parse_object(sha1);
>  	const char *parent = sha1_to_hex(sha1);
> +	const char *cp;
> +
>  	if (!obj)
>  		die("Unable to find commit parent %s", parent);
>  	if (obj->type != OBJ_COMMIT)
>  		die("Parent %s isn't a proper commit", parent);
> +	cp = strstr(sb->buf, parent);
> +	if (cp &&
> +	    sb->buf + 8 <= cp && !memcmp(cp - 8, "\nparent ", 8) &&
> +	    cp[40] == '\n') {
> +		error("duplicate parent %s ignored", parent);
> +		return;
> +	}

Would it not be better (simpler, cleaner) to just use an object flag?

Ciao,
Dscho

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Would it not be better (simpler, cleaner) to just use an object flag?

No.  Can you tell which flag is safe to use in this context without
digging around too much?

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

[Jakub Narebski]

On Tue, 3 June 2008, Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
>> Actually, it's trivial to convert to other SCM's, although I guess the 
>> conversion tools haven't really tried. You can always turn it into a 
>> series of multiple merges. Yes, you lose information, but it's not like 
>> you lose a huge amount.
> 
> One thing to worry about is what tree object you would give to each of
> these "artificially split" merge commits, though.

There shouldn't be, I think, a problem if octopus merge was done using
'octopus' merge strategy, which requires IIRC tree-level (trivial)
merge.  But true, it is a complication, unless we fake history more,
and always use result for octopus merge as a tree.

-- 
Jakub Narebski
Poland

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> On Tue, 3 June 2008, Junio C Hamano wrote:
>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>> 
>>> Actually, it's trivial to convert to other SCM's, although I guess the 
>>> conversion tools haven't really tried. You can always turn it into a 
>>> series of multiple merges. Yes, you lose information, but it's not like 
>>> you lose a huge amount.
>> 
>> One thing to worry about is what tree object you would give to each of
>> these "artificially split" merge commits, though.
>
> There shouldn't be, I think, a problem if octopus merge was done using
> 'octopus' merge strategy,...

You are sort-of right.

An octopus capable history may say "This is a merge between commit A, B
and C".  A trivial/naïve conversion to a foreign history that can only
express two-parent merges must say "This X is a merge between commit A and
B", followed by "This is a merge between X and C".  X, cross between A and
B, _should_ be a merge that can be reliably and trivially recreated.  This
actually is the reason why "my" octopus strategy implementation refuses to
record anything nontrivial.

But that's not something you should assume, as you can commit anything
with commit-tree.  Some people might even be using sg/merge-options series
parked in 'pu' that makes what the recorded parenthood and what the used
parents different even more.

A cleverer Octopus reimplementation might even try different orders in
which it performs its internal pairwise merges, and at that point the
order of recorded parents won't have any resemblance to the order their
trees were used in the internal pairwise merges.

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

[Jakub Narebski]

On Tue, 3 June 2008, Linus Torvalds wrote:
> 
> On Tue, 3 Jun 2008, Jakub Narebski wrote:
>>
>> I think that octopus merge (merge with more than two parents/legs) is 
>> feature which is unique to git (isn't it?).  Do you remember perhaps 
>> why it was introduced?
> 
> Well, mainly because the data structures supported the notion naturally.
> 
> Once you have 0, 1 or 2 parents, the logical progression is "many". 

Well, it of course depends on design.  For example Mercurial (from what
I have read in the documentation) has fixed width (two element) parents
array in revflog structure.  Commit can have no parents (root commit),
one parent, or two parents.  There is no place (again: AFAIK) for
octopus[*1*] merge.

Footnotes:
==========
[*1*] I assume that this kind of merge is called 'octopus' because it
      has more than two "legs" (parents), and not for example because
      first such merge had 8 parents?
-- 
Jakub Narebski
Poland

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> [*1*] I assume that this kind of merge is called 'octopus' because it
>       has more than two "legs" (parents), and not for example because
>       first such merge had 8 parents?

The first one ever was actually a pentapus, 211232b (Octopus merge of the
following five patches., 2005-05-05).

"gitk 211232b" was a beautiful sight back then, and it still is.  The
history was much simpler back then.

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

[Johannes Schindelin]

Hi,

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

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > Would it not be better (simpler, cleaner) to just use an object flag?
> 
> No.  Can you tell which flag is safe to use in this context without 
> digging around too much?

Was this not in builtin-commit.c?  AFAIR we said that the revision 
machinery must not use flags higher than 1<<12 or so, which would be left 
for users.

But I see that you already have the patch in 'master', so I guess you will 
not change it.

Ciao,
Dscho

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

[Matthieu Moy]

Jakub Narebski <jnareb@gmail.com> writes:

> I think that octopus merge (merge with more than two parents/legs) is 
> feature which is unique to git (isn't it?).  

bzr can do similar things:

bzr merge some-branch
bzr merge --force some-other-branch
bzr commit

Since bzr doesn't auto-commit after a merge, the above commands
actually creates only one revision with 3 parents (the --force is here
to let merge do it's job with uncommited changes in the tree).

-- 
Matthieu

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

[SZEDER Gábor]

Junio,

On Mon, Jun 02, 2008 at 10:17:42PM -0700, Junio C Hamano wrote:
> commit: drop duplicated parents
have you actually tried the testcase 'Hand committing of a redundant
merge removes dups' that you included with this commit (67bfc03)?  It
fails at the line 'EDITOR=: git commit -a'.

Regards,
Gábor

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

[Jakub Narebski]

On Tue, 3 June 2008, Matthieu Moy wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> I think that octopus merge (merge with more than two parents/legs) is 
>> feature which is unique to git (isn't it?).  
> 
> bzr can do similar things:
> 
> bzr merge some-branch
> bzr merge --force some-other-branch
> bzr commit
> 
> Since bzr doesn't auto-commit after a merge, the above commands
> actually creates only one revision with 3 parents (the --force is here
> to let merge do it's job with uncommited changes in the tree).

But does it store octopus merge as octopus: commit with more than
two parents?  In git making octopus merge is easy, perhaps too easy...


True, the above actually could be inferred from mentioned blog post
  http://vcscompare.blogspot.com/2008/05/meet-candidates.html
namely that there were problems with converting git repositories
containing octopus merges to Mercurial (and there was a bug in 
git-fast-export which made bzr-fast-import crash on them).

-- 
Jakub Narebski
Poland

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

[Matthieu Moy]

Jakub Narebski <jnareb@gmail.com> writes:

> On Tue, 3 June 2008, Matthieu Moy wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>> 
>>> I think that octopus merge (merge with more than two parents/legs) is 
>>> feature which is unique to git (isn't it?).  
>> 
>> bzr can do similar things:
>> 
>> bzr merge some-branch
>> bzr merge --force some-other-branch
>> bzr commit
>> 
>> Since bzr doesn't auto-commit after a merge, the above commands
>> actually creates only one revision with 3 parents (the --force is here
>> to let merge do it's job with uncommited changes in the tree).
>
> But does it store octopus merge as octopus: commit with more than
> two parents?

Yes, it's actually a single commit object with 3 parents.

-- 
Matthieu

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

[Linus Torvalds]

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

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

[Junio C Hamano]

SZEDER Gábor <szeder@ira.uka.de> writes:

> On Mon, Jun 02, 2008 at 10:17:42PM -0700, Junio C Hamano wrote:
>> commit: drop duplicated parents
> have you actually tried the testcase 'Hand committing of a redundant
> merge removes dups' that you included with this commit (67bfc03)?

Yes, three times (because it is in three integration branches 'master',
'next' and 'pu') on two different machines (my primary development machine
and my k.org account before pushing the results out).

... and I just updated two of my office boxes.

> ...  It
> fails at the line 'EDITOR=: git commit -a'.

Sorry, because it works for me (and presumably for many others --- I
haven't seen anybody else reporting the breakage you have), you need to
help others to diagnose it with a bit more details.

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

[Linus Torvalds]

On Tue, 3 Jun 2008, Jakub Narebski wrote:
> On Tue, 3 June 2008, Linus Torvalds wrote:
> > 
> > Once you have 0, 1 or 2 parents, the logical progression is "many". 
> 
> Well, it of course depends on design.  For example Mercurial (from what
> I have read in the documentation) has fixed width (two element) parents
> array in revflog structure.

Sure. And git very much on purpose made all basic data structures be text. 

I'm a UNIX weenie, not some VMS hack. Fixed-sized records are evil.

[ Yes, I made the hashes fixed-size binary blobs in the tree object. In 
  retrospect, that was probably a mistake. Not a huge one, but it's one of 
  the few things in the basic data structure that I'm sorry for. It 
  seemed to make sense at the time. ]

I do like how you can have arbitrary parenthood (well, arbitrary on a 
data structure level - we do restrict it in practice). Maybe it's not a 
hugely important thing, but it does allow more than just plain merges.

IOW, I could well imagine having an extra parent pointer that is not a 
"data merge" pointer, but a "concept merge" - you could have branches that 
have commits that point back to not the data in the tree, but to 
particular commits in another branch.

One of the things I could imagine using git for is to have "annotation 
branches" for things like code review etc. They'd be a real branch in 
their own right and with their own history, but at the same time they 
could well want to point back to the "code branch" that they annotate by 
considering that another parent in a "non-data merge" (and yes, you'd 
obviously have to use a special merge strategy for things like that, but 
you'd likely integrate it in some "annotation tool chain" rather than 
anything else).

			Linus

Commit annotations (was:: Octopus merge: unique (?) to git, but is it useful?)

[Jakub Narebski]

Linus Torvalds wrote:

> One of the things I could imagine using git for is to have "annotation 
> branches" for things like code review etc. They'd be a real branch in 
> their own right and with their own history, but at the same time they 
> could well want to point back to the "code branch" that they annotate by 
> considering that another parent in a "non-data merge" (and yes, you'd 
> obviously have to use a special merge strategy for things like that, but 
> you'd likely integrate it in some "annotation tool chain" rather than 
> anything else).

By the way, what is status of git-notes / commit annotations?  Did it got
abandoned, on hiatus, or what?

-- 
Jakub Narebski
Poland

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

[Johannes Schindelin]

Hi,

On Tue, 3 Jun 2008, Jakub Narebski wrote:

> Linus Torvalds wrote:
> 
> > One of the things I could imagine using git for is to have "annotation 
> > branches" for things like code review etc. They'd be a real branch in 
> > their own right and with their own history, but at the same time they 
> > could well want to point back to the "code branch" that they annotate 
> > by considering that another parent in a "non-data merge" (and yes, 
> > you'd obviously have to use a special merge strategy for things like 
> > that, but you'd likely integrate it in some "annotation tool chain" 
> > rather than anything else).
> 
> By the way, what is status of git-notes / commit annotations?  Did it got
> abandoned, on hiatus, or what?

You probably meant to Cc: me, and Linus, right?

I all but abandoned it.  It works, but I do not need it, and kind of 
waited for the guy who wanted them to chime in, so that I did not waste my 
time in vain.

IIRC it was Johan Herland, but I could be wrong.

Ciao,
Dscho

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

[SZEDER Gábor]

On Tue, Jun 03, 2008 at 12:30:34PM -0700, Junio C Hamano wrote:
> > ...  It
> > fails at the line 'EDITOR=: git commit -a'.
> 
> Sorry, because it works for me (and presumably for many others --- I
> haven't seen anybody else reporting the breakage you have), you need to
> help others to diagnose it with a bit more details.
With debug and verbose options it says following:

* expecting success: 

        git rev-parse second master >expect &&
        test_must_fail git merge second master &&
        git checkout master g &&
        echo "here comes the breakage" &&
        EDITOR=: git commit -a &&
        echo "survived!" &&
        git cat-file commit HEAD | sed -n -e "s/^parent //p" -e "/^$/q" >actual &&
        test_cmp expect actual



*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: empty ident  <szeder@neumann.(none)> not allowed
here comes the breakage
fatal: no commit message?  aborting commit.
* FAIL 18: Hand committing of a redundant merge removes dups
        
        
                git rev-parse second master >expect &&
                test_must_fail git merge second master &&
                git checkout master g &&
                echo "here comes the breakage" &&
                EDITOR=: git commit -a &&
                echo "survived!" &&
                git cat-file commit HEAD | sed -n -e "s/^parent //p" -e "/^$/q" >actual &&
                test_cmp expect actual
        
        

* failed 1 among 18 test(s)
make: *** [t7502-commit.sh] Error 1


My /bin/sh is dash, but it breaks with bash, too.

What else could/should I provide?

Regards,
Gábor

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

[Junio C Hamano]

SZEDER Gábor <szeder@ira.uka.de> writes:

> On Tue, Jun 03, 2008 at 12:30:34PM -0700, Junio C Hamano wrote:
>> > ...  It
>> > fails at the line 'EDITOR=: git commit -a'.
>> 
>> Sorry, because it works for me (and presumably for many others --- I
>> haven't seen anybody else reporting the breakage you have), you need to
>> help others to diagnose it with a bit more details.
> With debug and verbose options it says following:
>
> * expecting success: 
>
>         git rev-parse second master >expect &&
>         test_must_fail git merge second master &&
>         git checkout master g &&
>         echo "here comes the breakage" &&
>         EDITOR=: git commit -a &&
>         echo "survived!" &&
>         git cat-file commit HEAD | sed -n -e "s/^parent //p" -e "/^$/q" >actual &&
>         test_cmp expect actual
>
>
>
> *** Please tell me who you are.
> ...
> * failed 1 among 18 test(s)
> make: *** [t7502-commit.sh] Error 1
>
> My /bin/sh is dash, but it breaks with bash, too.
>
> What else could/should I provide?

Thanks, this is good enough.

I think the problem comes from the global removal of the two environment
variables, GIT_COMMITTER_{EMAIL,NAME} by an ealier bb1ae3f (commit: Show
committer if automatic, 2008-05-04).

Here is a potential fix.

The first hunk is the more relevant one; although the second one is also a
fix, it is independent.  It is a fix to unnecessarily loosely written test
that was done in early February.

 t/t7502-commit.sh |   44 ++++++++++++++++++++++++--------------------
 1 files changed, 24 insertions(+), 20 deletions(-)

diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index 22a13f7..7b659b9 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -171,13 +171,16 @@ sed '$d' < expect.tmp > expect
 rm -f expect.tmp
 echo "# Committer:
 #" >> expect
-unset GIT_COMMITTER_EMAIL
-unset GIT_COMMITTER_NAME
 
 test_expect_success 'committer is automatic' '
 
 	echo >>negative &&
-	git commit -e -m "sample"
+	(
+		unset GIT_COMMITTER_EMAIL
+		unset GIT_COMMITTER_NAME
+		# must fail because there is no change
+		test_must_fail git commit -e -m "sample"
+	) &&
 	head -n 8 .git/COMMIT_EDITMSG |	\
 	sed "s/^# Committer: .*/# Committer:/" >actual &&
 	test_cmp expect actual
@@ -193,23 +196,24 @@ chmod +x .git/FAKE_EDITOR
 
 test_expect_success 'do not fire editor in the presence of conflicts' '
 
-	git clean
-	echo f>g
-	git add g
-	git commit -myes
-	git branch second
-	echo master>g
-	echo g>h
-	git add g h
-	git commit -mmaster
-	git checkout second
-	echo second>g
-	git add g
-	git commit -msecond
-	git cherry-pick -n master
-	echo "editor not started" > .git/result
-	GIT_EDITOR=`pwd`/.git/FAKE_EDITOR git commit && exit 1  # should fail
-	test "`cat .git/result`" = "editor not started"
+	git clean -f &&
+	echo f >g &&
+	git add g &&
+	git commit -myes &&
+	git branch second &&
+	echo master >g
+	echo g >h
+	git add g h &&
+	git commit -mmaster &&
+	git checkout second &&
+	echo second >g
+	git add g &&
+	git commit -msecond &&
+	# Must fail due to conflict
+	test_must_fail git cherry-pick -n master &&
+	echo "editor not started" >.git/result &&
+	test_must_fail GIT_EDITOR="$(pwd)/.git/FAKE_EDITOR" git commit &&
+	test "$(cat .git/result)" = "editor not started"
 '
 
 pwd=`pwd`

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

[SZEDER Gábor]

On Tue, Jun 03, 2008 at 03:08:48PM -0700, Junio C Hamano wrote:
> Here is a potential fix.
> 
> The first hunk is the more relevant one; although the second one is also a
> fix, it is independent.  It is a fix to unnecessarily loosely written test
> that was done in early February.
Yes, the first hunk fixes the problem (and the second one does not
introduce any new breakage on my system ;)

However, I don't really see why the new test failed only at me...

Thanks,
Gábor

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

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

On Tue, Jun 03, 2008 at 07:40:21AM -0700, Linus Torvalds <torvalds@linux-foundation.org> 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.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Johan Herland]

On Tuesday 03 June 2008, Johannes Schindelin wrote:
> On Tue, 3 Jun 2008, Jakub Narebski wrote:
> > By the way, what is status of git-notes / commit annotations?  Did it
> > got abandoned, on hiatus, or what?
> 
> You probably meant to Cc: me, and Linus, right?
> 
> I all but abandoned it.  It works, but I do not need it, and kind of 
> waited for the guy who wanted them to chime in, so that I did not waste my 
> time in vain.
> 
> IIRC it was Johan Herland, but I could be wrong.

Yes, I made the first (severely misguided) implementations [1][2] which
prompted Dscho to create an alternative implementation [3]. Although Dscho's
design was certainly more Git-esque than mine (keeping the notes in a
(pseudo)branch instead of creating a totally separate infrastructure for
note storage), at some point his efforts stalled (due to a combination of
scalability problems and/or lack of interest, IIRC).

I was happy to see some of this work recently resumed by Geoffrey Irving
[4].

(Side note: It is funny how Geoffrey's patch-id cache can be seen as yet
another instance of the reverse-mapping softref mechanism I proposed as
part of the first git-notes implementation [5])

>From the initial interest in git-notes, and the sporadic requests that have
been posted since its first mention, it seems that git-notes would be a
useful feature for many Git users. However, neither me nor Dscho have the
time/interest to keep pushing it. Maybe it's time for someone else to pick
up the torch?


Have fun! :)

...Johan


[1]: http://thread.gmane.org/gmane.comp.version-control.git/46770/focus=48540
[2]: http://thread.gmane.org/gmane.comp.version-control.git/49052
[3]: http://thread.gmane.org/gmane.comp.version-control.git/52598
[4]: http://thread.gmane.org/gmane.comp.version-control.git/83484
[5]: http://thread.gmane.org/gmane.comp.version-control.git/49052/focus=49592

-- 
Johan Herland, <johan@herland.net>
www.herland.net

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

[Junio C Hamano]

Miklos Vajna <vmiklos@frugalware.org> writes:

> On Tue, Jun 03, 2008 at 07:40:21AM -0700, Linus Torvalds <torvalds@linux-foundation.org> 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.

Good eyes.  I guess I was sloppy when I wrote the log message for that
one and failed to talk about the bugfix ;-).

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

[Jeff King]

On Wed, Jun 04, 2008 at 01:10:20AM +0200, SZEDER Gábor wrote:

> Yes, the first hunk fixes the problem (and the second one does not
> introduce any new breakage on my system ;)
> 
> However, I don't really see why the new test failed only at me...

Because you were the only person (so far) whose gecos information wasn't
sufficient for git-commit to work. In Junio's case, the test script
accidentally unset the GIT_COMMITTER_{NAME,EMAIL} variables, which
caused git-commit to fall back on the information in /etc/passwd; it
worked, but it was doing something unintended. On your system, that
information wasn't available, so git-commit just broke.

-Peff

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

[Junio C Hamano]

SZEDER Gábor <szeder@ira.uka.de> writes:

> On Tue, Jun 03, 2008 at 03:08:48PM -0700, Junio C Hamano wrote:
>> Here is a potential fix.
>> 
>> The first hunk is the more relevant one; although the second one is also a
>> fix, it is independent.  It is a fix to unnecessarily loosely written test
>> that was done in early February.
> Yes, the first hunk fixes the problem (and the second one does not
> introduce any new breakage on my system ;)
>
> However, I don't really see why the new test failed only at me...

Perhaps it is because your GECOS setting leads to this error:

	fatal: empty ident  <szeder@neumann.(none)> not allowed

The reason the first hunk is a fix is because that particular test tries
to see what happens when the committer identity comes from the default
places (i.e. hostname, ident and GECOS) by removing the environment
variable.  For all the other tests, however, we explicitly set committer
and author identities by setting necessary environment variables so that
the tests will be repeatable for everybody.  That test, however, removed
the environment variable for all the later tests, which made them
unreliable (works for some people, not work for others).