{"thread":{"id":"13770","subject":"Octopus merge: unique (?) to git, but is it useful?","startedAt":"2008-06-03T01:14:02Z","lastAt":"2008-06-04T01:02:45Z","messageCount":30,"participants":["Jakub Narebski","Linus Torvalds","Daniel Villeneuve","Junio C Hamano","Johannes Schindelin","Matthieu Moy","SZEDER Gábor","Miklos Vajna","Johan Herland","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"78449","messageId":"200806030314.03252.jnareb@gmail.com","threadId":"13770","inReplyTo":null,"subject":"Octopus merge: unique (?) to git, but is it useful?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-03T01:14:02Z","receivedAt":"2008-06-03T01:14:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"I think that octopus merge (merge with more than two parents/legs) is \nfeature which is unique to git (isn't it?). Do you remember perhaps \nwhy it was introduced? What does it give, beside making it difficult \nto convert git repositories using this feature to others SCMs, for \nexample for comparison:\n http://vcscompare.blogspot.com/2008/05/meet-candidates.html\n\nTIA\n-- \nJakub Narebski\nPoland\n"},{"id":"78450","messageId":"alpine.LFD.1.10.0806021845210.3473@woody.linux-foundation.org","threadId":"13770","inReplyTo":"200806030314.03252.jnareb@gmail.com","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-06-03T02:05:03Z","receivedAt":"2008-06-03T02:05:03Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 3 Jun 2008, Jakub Narebski wrote:\n>\n> I think that octopus merge (merge with more than two parents/legs) is \n> feature which is unique to git (isn't it?). Do you remember perhaps \n> why it was introduced?\n\nWell, mainly because the data structures supported the notion naturally.\n\nOnce you have 0, 1 or 2 parents, the logical progression is \"many\". \n\n> What does it give, beside making it difficult \n> to convert git repositories using this feature to others SCMs\n\nActually, it's trivial to convert to other SCM's, although I guess the \nconversion tools haven't really tried. You can always turn it into a \nseries of multiple merges. Yes, you lose information, but it's not like \nyou lose a huge amount.\n\nAs to how useful it is.. We don't have a lot of them in the kernel, but I \ndo have to say that the ones we have generally tend to make perfect sense. \n\nTo see just octopus merges, do\n\n\tgit rev-list --parents HEAD |\n\t\tgrep '.* .* .* ' |\n\t\tgit diff-tree --stdin --pretty --always -S |\n\t\tless -S\n\nbut a couple of them are actually fake (same parent listed twice), due to \na confluence of (a) historically bad \"git merge\" semantics and (b) a bug \nthat made it not notice. In fact, that bug seems to have re-appeared, now \nthat I look at it!\n\nJunio: see kernel commits a733a5da9 and 52b097fff89, done as lately as \nFebruary of this year. We shouldn't allow that kind of thing, and in git \nwe have commits b389237ae and 6ea23343ce that were both about those kinds \nof mis-uses.\n\nThat said, most of those octopus merges look fine and actually give a \nnicer view of history. Of course, Len has been known to over-do it a bit ;)\n\n\t\tLinus\n"},{"id":"78451","messageId":"4844A986.1050209@videotron.ca","threadId":"13770","inReplyTo":"200806030314.03252.jnareb@gmail.com","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Daniel Villeneuve","fromEmail":"daniel2villeneuve@videotron.ca","sentAt":"2008-06-03T02:16:38Z","receivedAt":"2008-06-03T02:16:38Z","isPatch":false,"sender":{"key":"daniel2villeneuve@videotron.ca","avatar":null},"body":"Jakub Narebski wrote:\n> I think that octopus merge (merge with more than two parents/legs) is \n> feature which is unique to git (isn't it?). \nPRCS (http://prcs.sourceforge.net) allows to merge multiple branches \ninto the\ncurrent working directory, making the eventually committed version have \nmultiple\nparents.\n--\nDaniel Villeneuve\n"},{"id":"78454","messageId":"7v3anv5fy3.fsf@gitster.siamese.dyndns.org","threadId":"13770","inReplyTo":"alpine.LFD.1.10.0806021845210.3473@woody.linux-foundation.org","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-03T03:56:52Z","receivedAt":"2008-06-03T03:56:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Junio: see kernel commits a733a5da9 and 52b097fff89, done as lately as \n> February of this year. We shouldn't allow that kind of thing,...\n\nWell, we even allow fast-forwrad to be recorded as a true merge if the\nuser asks these days.\n\nAnd the thing is, that \"a733a5da9\" commit has a smoking-gun evidence that\na nonsense is asked by the committer.\n\n commit a733a5da97b238e3e3167d3d0aee8fe1e8d04e97\n Merge: 299cfe3... 299cfe3... 9e52797...\n Author: Len Brown \n AuthorDate: Thu Feb 7 03:38:22 2008 -0500\n Commit: Len Brown \n CommitDate: Thu Feb 7 03:38:22 2008 -0500\n\n Merge branches 'release' and 'fluff' into release\n\n Conflicts:\n\n drivers/acpi/scan.c\n include/linux/acpi.h\n\n Signed-off-by: Len Brown \n\n\"Merge branches 'RELEASE' and 'fluff' into RELEASE\"? That happens if you\nare _on_ release branch and say \"git merge release fluff\".\n\nHaving said that, I think what is happening is that the final set of\n\"other parents\" is computed inside git-merge out of MERGE_HEAD and that is\nusually what is recorded in the resulting merge, but if the merge results\nin a conflict with manual resolution, that information is not given to the\nfinal \"git commit\". The resulting commit records the parents out of HEAD\nand MERGE_HEAD. I do not think this part has changed from scripted\nversion of git-commit.\n"},{"id":"78455","messageId":"7vy75n3zus.fsf@gitster.siamese.dyndns.org","threadId":"13770","inReplyTo":"alpine.LFD.1.10.0806021845210.3473@woody.linux-foundation.org","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-03T04:29:47Z","receivedAt":"2008-06-03T04:29:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Actually, it's trivial to convert to other SCM's, although I guess the \n> conversion tools haven't really tried. You can always turn it into a \n> series of multiple merges. Yes, you lose information, but it's not like \n> you lose a huge amount.\n\nOne thing to worry about is what tree object you would give to each of\nthese \"artificially split\" merge commits, though.\n"},{"id":"78456","messageId":"7vskvv3xmx.fsf@gitster.siamese.dyndns.org","threadId":"13770","inReplyTo":"7v3anv5fy3.fsf@gitster.siamese.dyndns.org","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-03T05:17:42Z","receivedAt":"2008-06-03T05:17:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Having said that, I think what is happening is that the final set of\n> \"other parents\" is computed inside git-merge out of MERGE_HEAD and that is\n> usually what is recorded in the resulting merge, but if the merge results\n> in a conflict with manual resolution, that information is not given to the\n> final \"git commit\". The resulting commit records the parents out of HEAD\n> and MERGE_HEAD. I do not think this part has changed from scripted\n> version of git-commit.\n\nSorry, my thinko.\n\nThe scripted version obviously used commit-tree to omit the duplicated\nparent. Perhaps we can do something like this.\n\n-- >8 --\ncommit: drop duplicated parents\n\nThe scripted version of git-commit internally used git-commit-tree which\nomitted duplicated parents given from the command line. This prevented a\nnonsensical octopus merge from getting created even when you said \"git\nmerge A B\" while you are already on branch A.\n\nHowever, when git-commit was rewritten in C, this sanity check was lost.\nThis resurrects it.\n\nSigned-off-by: Junio C Hamano \n---\n builtin-commit.c | 9 +++++++++\n 1 files changed, 9 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-commit.c b/builtin-commit.c\nindex b294c1f..1d8d208 100644\n--- a/builtin-commit.c\n+++ b/builtin-commit.c\n@@ -883,10 +883,19 @@ static void add_parent(struct strbuf *sb, const unsigned char *sha1)\n {\n \tstruct object *obj = parse_object(sha1);\n \tconst char *parent = sha1_to_hex(sha1);\n+\tconst char *cp;\n+\n \tif (!obj)\n \t\tdie(\"Unable to find commit parent %s\", parent);\n \tif (obj->type != OBJ_COMMIT)\n \t\tdie(\"Parent %s isn't a proper commit\", parent);\n+\tcp = strstr(sb->buf, parent);\n+\tif (cp &&\n+\t sb->buf + 8 <= cp && !memcmp(cp - 8, \"\\nparent \", 8) &&\n+\t cp[40] == '\\n') {\n+\t\terror(\"duplicate parent %s ignored\", parent);\n+\t\treturn;\n+\t}\n \tstrbuf_addf(sb, \"parent %s\\n\", parent);\n }\n \n"},{"id":"78457","messageId":"alpine.DEB.1.00.0806030627440.13507@racer.site.net","threadId":"13770","inReplyTo":"7vskvv3xmx.fsf@gitster.siamese.dyndns.org","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-03T05:28:49Z","receivedAt":"2008-06-03T05:28:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 2 Jun 2008, Junio C Hamano wrote:\n\n> diff --git a/builtin-commit.c b/builtin-commit.c\n> index b294c1f..1d8d208 100644\n> --- a/builtin-commit.c\n> +++ b/builtin-commit.c\n> @@ -883,10 +883,19 @@ static void add_parent(struct strbuf *sb, const unsigned char *sha1)\n> {\n> \tstruct object *obj = parse_object(sha1);\n> \tconst char *parent = sha1_to_hex(sha1);\n> +\tconst char *cp;\n> +\n> \tif (!obj)\n> \t\tdie(\"Unable to find commit parent %s\", parent);\n> \tif (obj->type != OBJ_COMMIT)\n> \t\tdie(\"Parent %s isn't a proper commit\", parent);\n> +\tcp = strstr(sb->buf, parent);\n> +\tif (cp &&\n> +\t sb->buf + 8 <= cp && !memcmp(cp - 8, \"\\nparent \", 8) &&\n> +\t cp[40] == '\\n') {\n> +\t\terror(\"duplicate parent %s ignored\", parent);\n> +\t\treturn;\n> +\t}\n\nWould it not be better (simpler, cleaner) to just use an object flag?\n\nCiao,\nDscho\n"},{"id":"78459","messageId":"7vod6j3whp.fsf@gitster.siamese.dyndns.org","threadId":"13770","inReplyTo":"alpine.DEB.1.00.0806030627440.13507@racer.site.net","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-03T05:42:26Z","receivedAt":"2008-06-03T05:42:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Would it not be better (simpler, cleaner) to just use an object flag?\n\nNo. Can you tell which flag is safe to use in this context without\ndigging around too much?\n"},{"id":"78461","messageId":"200806030839.58214.jnareb@gmail.com","threadId":"13770","inReplyTo":"7vy75n3zus.fsf@gitster.siamese.dyndns.org","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-03T06:39:57Z","receivedAt":"2008-06-03T06:39:57Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Tue, 3 June 2008, Junio C Hamano wrote:\n> Linus Torvalds writes:\n> \n>> Actually, it's trivial to convert to other SCM's, although I guess the \n>> conversion tools haven't really tried. You can always turn it into a \n>> series of multiple merges. Yes, you lose information, but it's not like \n>> you lose a huge amount.\n> \n> One thing to worry about is what tree object you would give to each of\n> these \"artificially split\" merge commits, though.\n\nThere shouldn't be, I think, a problem if octopus merge was done using\n'octopus' merge strategy, which requires IIRC tree-level (trivial)\nmerge. But true, it is a complication, unless we fake history more,\nand always use result for octopus merge as a tree.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"78463","messageId":"7v1w3f3sdy.fsf@gitster.siamese.dyndns.org","threadId":"13770","inReplyTo":"200806030839.58214.jnareb@gmail.com","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-03T07:11:05Z","receivedAt":"2008-06-03T07:11:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> On Tue, 3 June 2008, Junio C Hamano wrote:\n>> Linus Torvalds writes:\n>> \n>>> Actually, it's trivial to convert to other SCM's, although I guess the \n>>> conversion tools haven't really tried. You can always turn it into a \n>>> series of multiple merges. Yes, you lose information, but it's not like \n>>> you lose a huge amount.\n>> \n>> One thing to worry about is what tree object you would give to each of\n>> these \"artificially split\" merge commits, though.\n>\n> There shouldn't be, I think, a problem if octopus merge was done using\n> 'octopus' merge strategy,...\n\nYou are sort-of right.\n\nAn octopus capable history may say \"This is a merge between commit A, B\nand C\". A trivial/naïve conversion to a foreign history that can only\nexpress two-parent merges must say \"This X is a merge between commit A and\nB\", followed by \"This is a merge between X and C\". X, cross between A and\nB, _should_ be a merge that can be reliably and trivially recreated. This\nactually is the reason why \"my\" octopus strategy implementation refuses to\nrecord anything nontrivial.\n\nBut that's not something you should assume, as you can commit anything\nwith commit-tree. Some people might even be using sg/merge-options series\nparked in 'pu' that makes what the recorded parenthood and what the used\nparents different even more.\n\nA cleverer Octopus reimplementation might even try different orders in\nwhich it performs its internal pairwise merges, and at that point the\norder of recorded parents won't have any resemblance to the order their\ntrees were used in the internal pairwise merges.\n"},{"id":"78465","messageId":"200806030932.03051.jnareb@gmail.com","threadId":"13770","inReplyTo":"alpine.LFD.1.10.0806021845210.3473@woody.linux-foundation.org","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-03T07:32:02Z","receivedAt":"2008-06-03T07:32:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Tue, 3 June 2008, Linus Torvalds wrote:\n> \n> On Tue, 3 Jun 2008, Jakub Narebski wrote:\n>>\n>> I think that octopus merge (merge with more than two parents/legs) is \n>> feature which is unique to git (isn't it?). Do you remember perhaps \n>> why it was introduced?\n> \n> Well, mainly because the data structures supported the notion naturally.\n> \n> Once you have 0, 1 or 2 parents, the logical progression is \"many\". \n\nWell, it of course depends on design. For example Mercurial (from what\nI have read in the documentation) has fixed width (two element) parents\narray in revflog structure. Commit can have no parents (root commit),\none parent, or two parents. There is no place (again: AFAIK) for\noctopus[*1*] merge.\n\nFootnotes:\n==========\n[*1*] I assume that this kind of merge is called 'octopus' because it\n has more than two \"legs\" (parents), and not for example because\n first such merge had 8 parents?\n-- \nJakub Narebski\nPoland\n"},{"id":"78466","messageId":"7vskvv2bux.fsf@gitster.siamese.dyndns.org","threadId":"13770","inReplyTo":"200806030932.03051.jnareb@gmail.com","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-03T07:53:26Z","receivedAt":"2008-06-03T07:53:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> [*1*] I assume that this kind of merge is called 'octopus' because it\n> has more than two \"legs\" (parents), and not for example because\n> first such merge had 8 parents?\n\nThe first one ever was actually a pentapus, 211232b (Octopus merge of the\nfollowing five patches., 2005-05-05).\n\n\"gitk 211232b\" was a beautiful sight back then, and it still is. The\nhistory was much simpler back then.\n"},{"id":"78468","messageId":"alpine.DEB.1.00.0806030929540.13507@racer.site.net","threadId":"13770","inReplyTo":"7vod6j3whp.fsf@gitster.siamese.dyndns.org","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-03T08:31:41Z","receivedAt":"2008-06-03T08:31:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 2 Jun 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Would it not be better (simpler, cleaner) to just use an object flag?\n> \n> No. Can you tell which flag is safe to use in this context without \n> digging around too much?\n\nWas this not in builtin-commit.c? AFAIR we said that the revision \nmachinery must not use flags higher than 1<<12 or so, which would be left \nfor users.\n\nBut I see that you already have the patch in 'master', so I guess you will \nnot change it.\n\nCiao,\nDscho\n"},{"id":"78472","messageId":"vpqabi2zvci.fsf@bauges.imag.fr","threadId":"13770","inReplyTo":"200806030314.03252.jnareb@gmail.com","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2008-06-03T10:06:05Z","receivedAt":"2008-06-03T10:06:05Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Jakub Narebski writes:\n\n> I think that octopus merge (merge with more than two parents/legs) is \n> feature which is unique to git (isn't it?). \n\nbzr can do similar things:\n\nbzr merge some-branch\nbzr merge --force some-other-branch\nbzr commit\n\nSince bzr doesn't auto-commit after a merge, the above commands\nactually creates only one revision with 3 parents (the --force is here\nto let merge do it's job with uncommited changes in the tree).\n\n-- \nMatthieu\n"},{"id":"78477","messageId":"20080603104009.GA559@neumann","threadId":"13770","inReplyTo":"7vskvv3xmx.fsf@gitster.siamese.dyndns.org","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2008-06-03T10:40:09Z","receivedAt":"2008-06-03T10:40:09Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Junio,\n\nOn Mon, Jun 02, 2008 at 10:17:42PM -0700, Junio C Hamano wrote:\n> commit: drop duplicated parents\nhave you actually tried the testcase 'Hand committing of a redundant\nmerge removes dups' that you included with this commit (67bfc03)? It\nfails at the line 'EDITOR=: git commit -a'.\n\nRegards,\nGábor\n"},{"id":"78482","messageId":"200806031327.52175.jnareb@gmail.com","threadId":"13770","inReplyTo":"vpqabi2zvci.fsf@bauges.imag.fr","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-03T11:27:51Z","receivedAt":"2008-06-03T11:27:51Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Tue, 3 June 2008, Matthieu Moy wrote:\n> Jakub Narebski writes:\n> \n>> I think that octopus merge (merge with more than two parents/legs) is \n>> feature which is unique to git (isn't it?). \n> \n> bzr can do similar things:\n> \n> bzr merge some-branch\n> bzr merge --force some-other-branch\n> bzr commit\n> \n> Since bzr doesn't auto-commit after a merge, the above commands\n> actually creates only one revision with 3 parents (the --force is here\n> to let merge do it's job with uncommited changes in the tree).\n\nBut does it store octopus merge as octopus: commit with more than\ntwo parents? In git making octopus merge is easy, perhaps too easy...\n\n\nTrue, the above actually could be inferred from mentioned blog post\n http://vcscompare.blogspot.com/2008/05/meet-candidates.html\nnamely that there were problems with converting git repositories\ncontaining octopus merges to Mercurial (and there was a bug in \ngit-fast-export which made bzr-fast-import crash on them).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"78485","messageId":"vpqlk1mu438.fsf@bauges.imag.fr","threadId":"13770","inReplyTo":"200806031327.52175.jnareb@gmail.com","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2008-06-03T11:53:47Z","receivedAt":"2008-06-03T11:53:47Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Jakub Narebski writes:\n\n> On Tue, 3 June 2008, Matthieu Moy wrote:\n>> Jakub Narebski writes:\n>> \n>>> I think that octopus merge (merge with more than two parents/legs) is \n>>> feature which is unique to git (isn't it?). \n>> \n>> bzr can do similar things:\n>> \n>> bzr merge some-branch\n>> bzr merge --force some-other-branch\n>> bzr commit\n>> \n>> Since bzr doesn't auto-commit after a merge, the above commands\n>> actually creates only one revision with 3 parents (the --force is here\n>> to let merge do it's job with uncommited changes in the tree).\n>\n> But does it store octopus merge as octopus: commit with more than\n> two parents?\n\nYes, it's actually a single commit object with 3 parents.\n\n-- \nMatthieu\n"},{"id":"78509","messageId":"alpine.LFD.1.10.0806030738340.3473@woody.linux-foundation.org","threadId":"13770","inReplyTo":"7v3anv5fy3.fsf@gitster.siamese.dyndns.org","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-06-03T14:40:21Z","receivedAt":"2008-06-03T14:40:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 2 Jun 2008, Junio C Hamano wrote:\n\n> \"Merge branches 'RELEASE' and 'fluff' into RELEASE\"? That happens if you\n> are _on_ release branch and say \"git merge release fluff\".\n\nRight. But git shouldn't do duplicate parents. I agree it's a mis-use of \ngit merge, but either we should have errored out or we should have pruned \nthe parents.\n\nYes, the end result is \"tecnically correct\", but it's not optimal.\n\n\t\tLinus\n"},{"id":"78532","messageId":"7vabi22u5h.fsf@gitster.siamese.dyndns.org","threadId":"13770","inReplyTo":"20080603104009.GA559@neumann","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-03T19:30:34Z","receivedAt":"2008-06-03T19:30:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"SZEDER Gábor writes:\n\n> On Mon, Jun 02, 2008 at 10:17:42PM -0700, Junio C Hamano wrote:\n>> commit: drop duplicated parents\n> have you actually tried the testcase 'Hand committing of a redundant\n> merge removes dups' that you included with this commit (67bfc03)?\n\nYes, three times (because it is in three integration branches 'master',\n'next' and 'pu') on two different machines (my primary development machine\nand my k.org account before pushing the results out).\n\n... and I just updated two of my office boxes.\n\n> ... It\n> fails at the line 'EDITOR=: git commit -a'.\n\nSorry, because it works for me (and presumably for many others --- I\nhaven't seen anybody else reporting the breakage you have), you need to\nhelp others to diagnose it with a bit more details.\n"},{"id":"78536","messageId":"alpine.LFD.1.10.0806031244290.3473@woody.linux-foundation.org","threadId":"13770","inReplyTo":"200806030932.03051.jnareb@gmail.com","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-06-03T19:54:31Z","receivedAt":"2008-06-03T19:54:31Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 3 Jun 2008, Jakub Narebski wrote:\n> On Tue, 3 June 2008, Linus Torvalds wrote:\n> > \n> > Once you have 0, 1 or 2 parents, the logical progression is \"many\". \n> \n> Well, it of course depends on design. For example Mercurial (from what\n> I have read in the documentation) has fixed width (two element) parents\n> array in revflog structure.\n\nSure. And git very much on purpose made all basic data structures be text. \n\nI'm a UNIX weenie, not some VMS hack. Fixed-sized records are evil.\n\n[ Yes, I made the hashes fixed-size binary blobs in the tree object. In \n retrospect, that was probably a mistake. Not a huge one, but it's one of \n the few things in the basic data structure that I'm sorry for. It \n seemed to make sense at the time. ]\n\nI do like how you can have arbitrary parenthood (well, arbitrary on a \ndata structure level - we do restrict it in practice). Maybe it's not a \nhugely important thing, but it does allow more than just plain merges.\n\nIOW, I could well imagine having an extra parent pointer that is not a \n\"data merge\" pointer, but a \"concept merge\" - you could have branches that \nhave commits that point back to not the data in the tree, but to \nparticular commits in another branch.\n\nOne of the things I could imagine using git for is to have \"annotation \nbranches\" for things like code review etc. They'd be a real branch in \ntheir own right and with their own history, but at the same time they \ncould well want to point back to the \"code branch\" that they annotate by \nconsidering that another parent in a \"non-data merge\" (and yes, you'd \nobviously have to use a special merge strategy for things like that, but \nyou'd likely integrate it in some \"annotation tool chain\" rather than \nanything else).\n\n\t\t\tLinus\n"},{"id":"78544","messageId":"200806032227.02951.jnareb@gmail.com","threadId":"13770","inReplyTo":"alpine.LFD.1.10.0806031244290.3473@woody.linux-foundation.org","subject":"Commit annotations (was:: Octopus merge: unique (?) to git, but is it useful?)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-03T20:27:02Z","receivedAt":"2008-06-03T20:27:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> One of the things I could imagine using git for is to have \"annotation \n> branches\" for things like code review etc. They'd be a real branch in \n> their own right and with their own history, but at the same time they \n> could well want to point back to the \"code branch\" that they annotate by \n> considering that another parent in a \"non-data merge\" (and yes, you'd \n> obviously have to use a special merge strategy for things like that, but \n> you'd likely integrate it in some \"annotation tool chain\" rather than \n> anything else).\n\nBy the way, what is status of git-notes / commit annotations? Did it got\nabandoned, on hiatus, or what?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"78546","messageId":"alpine.DEB.1.00.0806032131300.13507@racer.site.net","threadId":"13770","inReplyTo":"200806032227.02951.jnareb@gmail.com","subject":"Re: Commit annotations (was:: Octopus merge: unique (?) to git, but is it useful?)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-03T20:33:18Z","receivedAt":"2008-06-03T20:33:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 3 Jun 2008, Jakub Narebski wrote:\n\n> Linus Torvalds wrote:\n> \n> > One of the things I could imagine using git for is to have \"annotation \n> > branches\" for things like code review etc. They'd be a real branch in \n> > their own right and with their own history, but at the same time they \n> > could well want to point back to the \"code branch\" that they annotate \n> > by considering that another parent in a \"non-data merge\" (and yes, \n> > you'd obviously have to use a special merge strategy for things like \n> > that, but you'd likely integrate it in some \"annotation tool chain\" \n> > rather than anything else).\n> \n> By the way, what is status of git-notes / commit annotations? Did it got\n> abandoned, on hiatus, or what?\n\nYou probably meant to Cc: me, and Linus, right?\n\nI all but abandoned it. It works, but I do not need it, and kind of \nwaited for the guy who wanted them to chime in, so that I did not waste my \ntime in vain.\n\nIIRC it was Johan Herland, but I could be wrong.\n\nCiao,\nDscho\n"},{"id":"78548","messageId":"20080603203924.GA6588@neumann","threadId":"13770","inReplyTo":"7vabi22u5h.fsf@gitster.siamese.dyndns.org","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2008-06-03T20:39:24Z","receivedAt":"2008-06-03T20:39:24Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Tue, Jun 03, 2008 at 12:30:34PM -0700, Junio C Hamano wrote:\n> > ... It\n> > fails at the line 'EDITOR=: git commit -a'.\n> \n> Sorry, because it works for me (and presumably for many others --- I\n> haven't seen anybody else reporting the breakage you have), you need to\n> help others to diagnose it with a bit more details.\nWith debug and verbose options it says following:\n\n* expecting success: \n\n git rev-parse second master >expect &&\n test_must_fail git merge second master &&\n git checkout master g &&\n echo \"here comes the breakage\" &&\n EDITOR=: git commit -a &&\n echo \"survived!\" &&\n git cat-file commit HEAD | sed -n -e \"s/^parent //p\" -e \"/^$/q\" >actual &&\n test_cmp expect actual\n\n\n\n*** Please tell me who you are.\n\nRun\n\n git config --global user.email \"you@example.com\"\n git config --global user.name \"Your Name\"\n\nto set your account's default identity.\nOmit --global to set the identity only in this repository.\n\nfatal: empty ident not allowed\nhere comes the breakage\nfatal: no commit message? aborting commit.\n* FAIL 18: Hand committing of a redundant merge removes dups\n \n \n git rev-parse second master >expect &&\n test_must_fail git merge second master &&\n git checkout master g &&\n echo \"here comes the breakage\" &&\n EDITOR=: git commit -a &&\n echo \"survived!\" &&\n git cat-file commit HEAD | sed -n -e \"s/^parent //p\" -e \"/^$/q\" >actual &&\n test_cmp expect actual\n \n \n\n* failed 1 among 18 test(s)\nmake: *** [t7502-commit.sh] Error 1\n\n\nMy /bin/sh is dash, but it breaks with bash, too.\n\nWhat else could/should I provide?\n\nRegards,\nGábor\n"},{"id":"78558","messageId":"7vk5h6189b.fsf@gitster.siamese.dyndns.org","threadId":"13770","inReplyTo":"20080603203924.GA6588@neumann","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-03T22:08:48Z","receivedAt":"2008-06-03T22:08:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"SZEDER Gábor writes:\n\n> On Tue, Jun 03, 2008 at 12:30:34PM -0700, Junio C Hamano wrote:\n>> > ... It\n>> > fails at the line 'EDITOR=: git commit -a'.\n>> \n>> Sorry, because it works for me (and presumably for many others --- I\n>> haven't seen anybody else reporting the breakage you have), you need to\n>> help others to diagnose it with a bit more details.\n> With debug and verbose options it says following:\n>\n> * expecting success: \n>\n> git rev-parse second master >expect &&\n> test_must_fail git merge second master &&\n> git checkout master g &&\n> echo \"here comes the breakage\" &&\n> EDITOR=: git commit -a &&\n> echo \"survived!\" &&\n> git cat-file commit HEAD | sed -n -e \"s/^parent //p\" -e \"/^$/q\" >actual &&\n> test_cmp expect actual\n>\n>\n>\n> *** Please tell me who you are.\n> ...\n> * failed 1 among 18 test(s)\n> make: *** [t7502-commit.sh] Error 1\n>\n> My /bin/sh is dash, but it breaks with bash, too.\n>\n> What else could/should I provide?\n\nThanks, this is good enough.\n\nI think the problem comes from the global removal of the two environment\nvariables, GIT_COMMITTER_{EMAIL,NAME} by an ealier bb1ae3f (commit: Show\ncommitter if automatic, 2008-05-04).\n\nHere is a potential fix.\n\nThe first hunk is the more relevant one; although the second one is also a\nfix, it is independent. It is a fix to unnecessarily loosely written test\nthat was done in early February.\n\n t/t7502-commit.sh | 44 ++++++++++++++++++++++++--------------------\n 1 files changed, 24 insertions(+), 20 deletions(-)\n\ndiff --git a/t/t7502-commit.sh b/t/t7502-commit.sh\nindex 22a13f7..7b659b9 100755\n--- a/t/t7502-commit.sh\n+++ b/t/t7502-commit.sh\n@@ -171,13 +171,16 @@ sed '$d' < expect.tmp > expect\n rm -f expect.tmp\n echo \"# Committer:\n #\" >> expect\n-unset GIT_COMMITTER_EMAIL\n-unset GIT_COMMITTER_NAME\n \n test_expect_success 'committer is automatic' '\n \n \techo >>negative &&\n-\tgit commit -e -m \"sample\"\n+\t(\n+\t\tunset GIT_COMMITTER_EMAIL\n+\t\tunset GIT_COMMITTER_NAME\n+\t\t# must fail because there is no change\n+\t\ttest_must_fail git commit -e -m \"sample\"\n+\t) &&\n \thead -n 8 .git/COMMIT_EDITMSG |\t\\\n \tsed \"s/^# Committer: .*/# Committer:/\" >actual &&\n \ttest_cmp expect actual\n@@ -193,23 +196,24 @@ chmod +x .git/FAKE_EDITOR\n \n test_expect_success 'do not fire editor in the presence of conflicts' '\n \n-\tgit clean\n-\techo f>g\n-\tgit add g\n-\tgit commit -myes\n-\tgit branch second\n-\techo master>g\n-\techo g>h\n-\tgit add g h\n-\tgit commit -mmaster\n-\tgit checkout second\n-\techo second>g\n-\tgit add g\n-\tgit commit -msecond\n-\tgit cherry-pick -n master\n-\techo \"editor not started\" > .git/result\n-\tGIT_EDITOR=`pwd`/.git/FAKE_EDITOR git commit && exit 1 # should fail\n-\ttest \"`cat .git/result`\" = \"editor not started\"\n+\tgit clean -f &&\n+\techo f >g &&\n+\tgit add g &&\n+\tgit commit -myes &&\n+\tgit branch second &&\n+\techo master >g\n+\techo g >h\n+\tgit add g h &&\n+\tgit commit -mmaster &&\n+\tgit checkout second &&\n+\techo second >g\n+\tgit add g &&\n+\tgit commit -msecond &&\n+\t# Must fail due to conflict\n+\ttest_must_fail git cherry-pick -n master &&\n+\techo \"editor not started\" >.git/result &&\n+\ttest_must_fail GIT_EDITOR=\"$(pwd)/.git/FAKE_EDITOR\" git commit &&\n+\ttest \"$(cat .git/result)\" = \"editor not started\"\n '\n \n pwd=`pwd`\n"},{"id":"78567","messageId":"20080603231020.GB6588@neumann","threadId":"13770","inReplyTo":"7vk5h6189b.fsf@gitster.siamese.dyndns.org","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2008-06-03T23:10:20Z","receivedAt":"2008-06-03T23:10:20Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Tue, Jun 03, 2008 at 03:08:48PM -0700, Junio C Hamano wrote:\n> Here is a potential fix.\n> \n> The first hunk is the more relevant one; although the second one is also a\n> fix, it is independent. It is a fix to unnecessarily loosely written test\n> that was done in early February.\nYes, the first hunk fixes the problem (and the second one does not\nintroduce any new breakage on my system ;)\n\nHowever, I don't really see why the new test failed only at me...\n\nThanks,\nGábor\n"},{"id":"78569","messageId":"20080603231151.GR29404@genesis.frugalware.org","threadId":"13770","inReplyTo":"alpine.LFD.1.10.0806030738340.3473@woody.linux-foundation.org","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-06-03T23:11:51Z","receivedAt":"2008-06-03T23:11:51Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Tue, Jun 03, 2008 at 07:40:21AM -0700, Linus Torvalds wrote:\n> Right. But git shouldn't do duplicate parents. I agree it's a mis-use of \n> git merge, but either we should have errored out or we should have pruned \n> the parents.\n> \n> Yes, the end result is \"tecnically correct\", but it's not optimal.\n\nI think the current git-merge.sh already handles this: 6ea23343\nintroduced the usage of git-show-branch --independent to filter out\nduplicated parents.\n"},{"id":"78573","messageId":"200806040159.28603.johan@herland.net","threadId":"13770","inReplyTo":"alpine.DEB.1.00.0806032131300.13507@racer.site.net","subject":"Re: Commit annotations (was:: Octopus merge: unique (?) to git, but is it useful?)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2008-06-03T23:59:28Z","receivedAt":"2008-06-03T23:59:28Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Tuesday 03 June 2008, Johannes Schindelin wrote:\n> On Tue, 3 Jun 2008, Jakub Narebski wrote:\n> > By the way, what is status of git-notes / commit annotations? Did it\n> > got abandoned, on hiatus, or what?\n> \n> You probably meant to Cc: me, and Linus, right?\n> \n> I all but abandoned it. It works, but I do not need it, and kind of \n> waited for the guy who wanted them to chime in, so that I did not waste my \n> time in vain.\n> \n> IIRC it was Johan Herland, but I could be wrong.\n\nYes, I made the first (severely misguided) implementations [1][2] which\nprompted Dscho to create an alternative implementation [3]. Although Dscho's\ndesign was certainly more Git-esque than mine (keeping the notes in a\n(pseudo)branch instead of creating a totally separate infrastructure for\nnote storage), at some point his efforts stalled (due to a combination of\nscalability problems and/or lack of interest, IIRC).\n\nI was happy to see some of this work recently resumed by Geoffrey Irving\n[4].\n\n(Side note: It is funny how Geoffrey's patch-id cache can be seen as yet\nanother instance of the reverse-mapping softref mechanism I proposed as\npart of the first git-notes implementation [5])\n\n>From the initial interest in git-notes, and the sporadic requests that have\nbeen posted since its first mention, it seems that git-notes would be a\nuseful feature for many Git users. However, neither me nor Dscho have the\ntime/interest to keep pushing it. Maybe it's time for someone else to pick\nup the torch?\n\n\nHave fun! :)\n\n...Johan\n\n\n[1]: http://thread.gmane.org/gmane.comp.version-control.git/46770/focus=48540\n[2]: http://thread.gmane.org/gmane.comp.version-control.git/49052\n[3]: http://thread.gmane.org/gmane.comp.version-control.git/52598\n[4]: http://thread.gmane.org/gmane.comp.version-control.git/83484\n[5]: http://thread.gmane.org/gmane.comp.version-control.git/49052/focus=49592\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"78576","messageId":"7vbq2i11jz.fsf@gitster.siamese.dyndns.org","threadId":"13770","inReplyTo":"20080603231151.GR29404@genesis.frugalware.org","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-04T00:33:36Z","receivedAt":"2008-06-04T00:33:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miklos Vajna writes:\n\n> On Tue, Jun 03, 2008 at 07:40:21AM -0700, Linus Torvalds wrote:\n>> Right. But git shouldn't do duplicate parents. I agree it's a mis-use of \n>> git merge, but either we should have errored out or we should have pruned \n>> the parents.\n>> \n>> Yes, the end result is \"tecnically correct\", but it's not optimal.\n>\n> I think the current git-merge.sh already handles this: 6ea23343\n> introduced the usage of git-show-branch --independent to filter out\n> duplicated parents.\n\nGood eyes. I guess I was sloppy when I wrote the log message for that\none and failed to talk about the bugfix ;-).\n"},{"id":"78577","messageId":"20080604003516.GA24232@sigill.intra.peff.net","threadId":"13770","inReplyTo":"20080603231020.GB6588@neumann","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-04T00:35:16Z","receivedAt":"2008-06-04T00:35:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jun 04, 2008 at 01:10:20AM +0200, SZEDER Gábor wrote:\n\n> Yes, the first hunk fixes the problem (and the second one does not\n> introduce any new breakage on my system ;)\n> \n> However, I don't really see why the new test failed only at me...\n\nBecause you were the only person (so far) whose gecos information wasn't\nsufficient for git-commit to work. In Junio's case, the test script\naccidentally unset the GIT_COMMITTER_{NAME,EMAIL} variables, which\ncaused git-commit to fall back on the information in /etc/passwd; it\nworked, but it was doing something unintended. On your system, that\ninformation wasn't available, so git-commit just broke.\n\n-Peff\n"},{"id":"78580","messageId":"7v7id6107e.fsf@gitster.siamese.dyndns.org","threadId":"13770","inReplyTo":"20080603231020.GB6588@neumann","subject":"Re: Octopus merge: unique (?) to git, but is it useful?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-04T01:02:45Z","receivedAt":"2008-06-04T01:02:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"SZEDER Gábor writes:\n\n> On Tue, Jun 03, 2008 at 03:08:48PM -0700, Junio C Hamano wrote:\n>> Here is a potential fix.\n>> \n>> The first hunk is the more relevant one; although the second one is also a\n>> fix, it is independent. It is a fix to unnecessarily loosely written test\n>> that was done in early February.\n> Yes, the first hunk fixes the problem (and the second one does not\n> introduce any new breakage on my system ;)\n>\n> However, I don't really see why the new test failed only at me...\n\nPerhaps it is because your GECOS setting leads to this error:\n\n\tfatal: empty ident not allowed\n\nThe reason the first hunk is a fix is because that particular test tries\nto see what happens when the committer identity comes from the default\nplaces (i.e. hostname, ident and GECOS) by removing the environment\nvariable. For all the other tests, however, we explicitly set committer\nand author identities by setting necessary environment variables so that\nthe tests will be repeatable for everybody. That test, however, removed\nthe environment variable for all the later tests, which made them\nunreliable (works for some people, not work for others).\n"}]}