{"thread":{"id":"11474","subject":"Octopus? Really? Interesting...","startedAt":"2008-01-04T18:28:41Z","lastAt":"2008-01-04T22:42:57Z","messageCount":2,"participants":["Jon Loeliger","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"64450","messageId":"1199471321.3133.22.camel@ld0161-tx32","threadId":"11474","inReplyTo":null,"subject":"Octopus? Really? Interesting...","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2008-01-04T18:28:41Z","receivedAt":"2008-01-04T18:28:41Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"Guys,\n\nSo, I brain-wedged a merge here just now\nand was surprised to see that a simple\nfetch-n-merge yielded an octopus merge.\nI was expecting a fast-forward.  So I went\nback and reviewed.  What actually happend\nwas this:\n\n    $ git checkout master\n    $ git fetch origin\n    # check it out... looks great ... let's merge it\n    $ git merge master origin/master\n    merge performed by octopus.\n\nOh, yeah.  Duh.  I did name two branches.  Feh.\n\nCouple questions:\n\n    Is it ever NOT the case, that if you are on one\n    branch (\"master\") and name it as a \"to be merged\"\n    branch along with some others, that we can simplify\n    the request by noting that it is the same as the\n    current \"to be merged into\" target branch?\n\n    Other than creating a log message with \"merged\n    by octopus\", will this merge be content-identical\n    to the obvious simplified merge?\n\nThanks,\njdl\n"},{"id":"64471","messageId":"7vhchti55a.fsf@gitster.siamese.dyndns.org","threadId":"11474","inReplyTo":"1199471321.3133.22.camel@ld0161-tx32","subject":"Re: Octopus? Really? Interesting...","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-04T22:42:57Z","receivedAt":"2008-01-04T22:42:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger <jdl@freescale.com> writes:\n\n> Couple questions:\n>\n>     Is it ever NOT the case, that if you are on one\n>     branch (\"master\") and name it as a \"to be merged\"\n>     branch along with some others, that we can simplify\n>     the request by noting that it is the same as the\n>     current \"to be merged into\" target branch?\n\nYes we can, but \"filter ancestors out from the remotes\"\ncomputation does not happen before the merge strategy is chosen.\n\n>     Other than creating a log message with \"merged\n>     by octopus\", will this merge be content-identical\n>     to the obvious simplified merge?\n\nI think octopus actually tries to be careful not to run the\nread-tree 3-way merge when merging a true ancestor (see ll.77-87\nin git-merge-octopus.sh, but see below), so the resulting tree\nshould be identical to \"-s resolve\" merge.\n\nBut that does not mean the user's wish to record such a commit\nas one ancestor should not be honored, and I think there\nactually is a benign bug there.  Due to the \"Already up-to-date\nwith $SHA1\" part, the codepath that says \"Fast forwarding to:\"\nnever actually triggers, so in practice we end up dropping any\ntrue ancestor from the parent list of the resulting merge.  That\ncontradicts the comment in ll.77-87 that suggests we try not to\noutsmart the user who told us to create such an octopus for\nunfathomable reason ;-)\n"}]}