{"thread":{"id":"20320","subject":"Have git-merge-base support multiple IDs","startedAt":"2009-07-31T15:51:25Z","lastAt":"2009-08-03T21:52:32Z","messageCount":4,"participants":["Jan Engelhardt","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"119281","messageId":"alpine.LSU.2.00.0907311745100.4901@fbirervta.pbzchgretzou.qr","threadId":"20320","inReplyTo":null,"subject":"Have git-merge-base support multiple IDs","fromName":"Jan Engelhardt","fromEmail":"jengelh@medozas.de","sentAt":"2009-07-31T15:51:25Z","receivedAt":"2009-07-31T15:51:25Z","isPatch":false,"sender":{"key":"jengelh@medozas.de","avatar":null},"body":"Hi,\n\n\nI am using git merge-base as sort of a hack to determine where to start \nrebasing.\nSuppose this is the commit log (git log --oneline), of course, all \nunpublished, which is why rebase comes in:\n\n  98683793  Fix For faae2553\n  3365a01b  Fix For ab80794f\n  62943a23  Feature Baz\n  ab80794f  Feature Bar\n  faae2553  Feature Foo\n\nTo determine the rebase point (i.e. first commit in a series),\none can (ab)use git-merge-base:\n\n  p=$(git merge-base ab80794f faae2553)\n  git re -i ${p}^\n\nAnd then reorder ab80794f, faae2553 to squash the fixes into the \nappropriate commits. This practice works well somewhat.\nThe twist is that merge-base in git 1.6.3.3 happens to ignore any \nfurther arguments following two IDs. In short:\n\n  git merge-base A B C...\n\nOnly yields the merge-base of A and B, and ignores C...\nPerhaps this missing feature could be added in a future version?\n"},{"id":"119286","messageId":"4A731A39.3090506@drmicha.warpmail.net","threadId":"20320","inReplyTo":"alpine.LSU.2.00.0907311745100.4901@fbirervta.pbzchgretzou.qr","subject":"Re: Have git-merge-base support multiple IDs","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-07-31T16:22:17Z","receivedAt":"2009-07-31T16:22:17Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jan Engelhardt venit, vidit, dixit 31.07.2009 17:51:\n> Hi,\n> \n> \n> I am using git merge-base as sort of a hack to determine where to start \n> rebasing.\n> Suppose this is the commit log (git log --oneline), of course, all \n> unpublished, which is why rebase comes in:\n> \n>   98683793  Fix For faae2553\n>   3365a01b  Fix For ab80794f\n>   62943a23  Feature Baz\n>   ab80794f  Feature Bar\n>   faae2553  Feature Foo\n> \n> To determine the rebase point (i.e. first commit in a series),\n> one can (ab)use git-merge-base:\n> \n>   p=$(git merge-base ab80794f faae2553)\n>   git re -i ${p}^\n> \n> And then reorder ab80794f, faae2553 to squash the fixes into the \n> appropriate commits. This practice works well somewhat.\n> The twist is that merge-base in git 1.6.3.3 happens to ignore any \n> further arguments following two IDs. In short:\n> \n>   git merge-base A B C...\n> \n> Only yields the merge-base of A and B, and ignores C...\n\nUhm, are you sure about this?\nThe first argument is special.\nmerge-base computes the merge base between two commits:\n- the first argument\n- a (hypothetical) merge between all other arguments.\n\nIt may look a if C was ignored, though.\n\nMichael\n"},{"id":"119402","messageId":"alpine.LSU.2.00.0908031539070.2603@fbirervta.pbzchgretzou.qr","threadId":"20320","inReplyTo":"4A731A39.3090506@drmicha.warpmail.net","subject":"Re: Have git-merge-base support multiple IDs","fromName":"Jan Engelhardt","fromEmail":"jengelh@medozas.de","sentAt":"2009-08-03T13:39:55Z","receivedAt":"2009-08-03T13:39:55Z","isPatch":false,"sender":{"key":"jengelh@medozas.de","avatar":null},"body":"\nOn Friday 2009-07-31 18:22, Michael J Gruber wrote:\n>Jan Engelhardt venit, vidit, dixit 31.07.2009 17:51:\n>> To determine the rebase point (i.e. first commit in a series),\n>> one can (ab)use git-merge-base:\n>> \n>>   p=$(git merge-base ab80794f faae2553)\n>>   git re -i ${p}^\n>> \n>> The twist is that merge-base in git 1.6.3.3 happens to ignore any \n>> further arguments following two IDs. In short:\n>> \n>>   git merge-base A B C...\n>> \n>> Only yields the merge-base of A and B, and ignores C...\n>\n>Uhm, are you sure about this?\n>The first argument is special. merge-base computes the merge base between two commits:\n>- the first argument\n>- a (hypothetical) merge between all other arguments.\n>It may look a if C was ignored, though.\n\nHm indeed. Is there a better way to find the common ancestor of commits?\n"},{"id":"119489","messageId":"4A775C20.9070109@drmicha.warpmail.net","threadId":"20320","inReplyTo":"alpine.LSU.2.00.0908031539070.2603@fbirervta.pbzchgretzou.qr","subject":"Re: Have git-merge-base support multiple IDs","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-08-03T21:52:32Z","receivedAt":"2009-08-03T21:52:32Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jan Engelhardt venit, vidit, dixit 03.08.2009 15:39:\n> \n> On Friday 2009-07-31 18:22, Michael J Gruber wrote:\n>> Jan Engelhardt venit, vidit, dixit 31.07.2009 17:51:\n>>> To determine the rebase point (i.e. first commit in a series),\n>>> one can (ab)use git-merge-base:\n>>>\n>>>   p=$(git merge-base ab80794f faae2553)\n>>>   git re -i ${p}^\n>>>\n>>> The twist is that merge-base in git 1.6.3.3 happens to ignore any \n>>> further arguments following two IDs. In short:\n>>>\n>>>   git merge-base A B C...\n>>>\n>>> Only yields the merge-base of A and B, and ignores C...\n>>\n>> Uhm, are you sure about this?\n>> The first argument is special. merge-base computes the merge base between two commits:\n>> - the first argument\n>> - a (hypothetical) merge between all other arguments.\n>> It may look a if C was ignored, though.\n> \n> Hm indeed. Is there a better way to find the common ancestor of commits?\n\nI haven't tested thorougly, but at least for the standard example\n\ngit show-branch --merge-base A B C\n\nseems to do what you want. Note that for this command, the order of\narguments is irrelevant, whereas for git merge-base it makes a huge\ndifference. Also, git show-branch documentation is a bit outdated. I\nexpect to look into this...\n\nMichael\n"}]}