{"thread":{"id":"27074","subject":"[PATCH/resend] Documentation: update to git-merge-base --octopus","startedAt":"2011-04-12T16:14:05Z","lastAt":"2011-04-15T17:18:06Z","messageCount":7,"participants":["Vincent van Ravesteijn","Junio C Hamano","Jonathan Nieder"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"165696","messageId":"4DA47A4D.80909@lyx.org","threadId":"27074","inReplyTo":null,"subject":"[PATCH/resend] Documentation: update to git-merge-base --octopus","fromName":"Vincent van Ravesteijn","fromEmail":"vfr@lyx.org","sentAt":"2011-04-12T16:14:05Z","receivedAt":"2011-04-12T16:14:05Z","isPatch":true,"sender":{"key":"vfr@lyx.org","avatar":"https://avatars.githubusercontent.com/u/687868?v=4"},"body":"1) Make it clear that when the --octopus parameter is given to 'git merge-base',\nonly a set of commits is expected as the parameter. On the other hand, in the\ncase without the --octopus parameter, it is necessary to supply a single commit\nand a set. Moreover, in the case of --octopus merging, a single commit is also valid,\nwhich is not the case otherwise.\n\n2) Add a sentence to the discussion that when --octopus is used, we do expect '2'\nas the result.\n\nSigned-off-by: Vincent van Ravesteijn <vfr@lyx.org>\n---\nSorry for the noise caused by the previous attempt(s). Apparently my attempts\nto let Thunderbird _not wrap_ the lines were counterproductive.\n\nHere is the patch again.\n\n Documentation/git-merge-base.txt |    6 +++++-\n builtin/merge-base.c             |    3 ++-\n 2 files changed, 7 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt\nindex eedef1b..1bac04f 100644\n--- a/Documentation/git-merge-base.txt\n+++ b/Documentation/git-merge-base.txt\n@@ -9,7 +9,8 @@ git-merge-base - Find as good common ancestors as possible for a merge\n SYNOPSIS\n --------\n [verse]\n-'git merge-base' [-a|--all] [--octopus] <commit> <commit>...\n+'git merge-base' [-a|--all] <commit> <commit>...\n+'git merge-base' [-a|--all] --octopus <commit>...\n 'git merge-base' --independent <commit>...\n\n DESCRIPTION\n@@ -89,6 +90,9 @@ and the result of `git merge-base A M` is '1'.  Commit '2' is also a\n common ancestor between 'A' and 'M', but '1' is a better common ancestor,\n because '2' is an ancestor of '1'.  Hence, '2' is not a merge base.\n\n+When the option `--octopus` is given, the result of `git merge-base A B C`\n+will be '2', because '2' is the common ancestor of all branches.\n+\n When the history involves criss-cross merges, there can be more than one\n 'best' common ancestor for two commits.  For example, with this topology:\n\ndiff --git a/builtin/merge-base.c b/builtin/merge-base.c\nindex 96dd160..4f30f1b 100644\n--- a/builtin/merge-base.c\n+++ b/builtin/merge-base.c\n@@ -23,7 +23,8 @@ static int show_merge_base(struct commit **rev, int rev_nr, int show_all)\n }\n\n static const char * const merge_base_usage[] = {\n-\t\"git merge-base [-a|--all] [--octopus] <commit> <commit>...\",\n+\t\"git merge-base [-a|--all] <commit> <commit>...\",\n+\t\"git merge-base [-a|--all] --octopus <commit>...\",\n \t\"git merge-base --independent <commit>...\",\n \tNULL\n };\n-- \n1.7.3.1.msysgit.0\n"},{"id":"165698","messageId":"7vaafvqsu0.fsf@alter.siamese.dyndns.org","threadId":"27074","inReplyTo":"4DA47A4D.80909@lyx.org","subject":"Re: [PATCH/resend] Documentation: update to git-merge-base --octopus","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-12T17:31:51Z","receivedAt":"2011-04-12T17:31:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Vincent van Ravesteijn <vfr@lyx.org> writes:\n\n> Sorry for the noise caused by the previous attempt(s). Apparently my attempts\n> to let Thunderbird _not wrap_ the lines were counterproductive.\n\nI was wondering what that was about.\n\n> +When the option `--octopus` is given, the result of `git merge-base A B C`\n> +will be '2', because '2' is the common ancestor of all branches.\n\nWouldn't it be easier to read if you had the option in the command line, i.e.\n\n    The result of `git merge-base --octopus A B C` is '2' because...\n\nwithout \"When ... given\" that now become noisewords?\n"},{"id":"165707","messageId":"20110412194558.GB1209@elie","threadId":"27074","inReplyTo":"4DA47A4D.80909@lyx.org","subject":"Re: [PATCH/resend] Documentation: update to git-merge-base --octopus","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-12T19:45:58Z","receivedAt":"2011-04-12T19:45:58Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Vincent,\n\nVincent van Ravesteijn wrote:\n\n> On the other hand, in the\n> case without the --octopus parameter, it is necessary to supply a single commit\n> and a set. Moreover, in the case of --octopus merging, a single commit is also valid,\n> which is not the case otherwise.\n\nSo to summarize: unlike plain merge-base, merge-base --octopus only\nrequires at least one commit argument, and this patch updates the\nsynopsis to reflect that.  Good catch.\n\n> 2) Add a sentence to the discussion that when --octopus is used, we do expect '2'\n> as the result.\n\nAdding an example use of --octopus to the DISCUSSION section makes a\nlot of sense.  At first I thought this was being added to the\nDESCRIPTION section, which led me to suggest something like the\nfollowing:\n\n DESCRIPTION\n -----------\n 'git merge-base' finds best common ancestors between two commits to\n use in a three-way merge.  [... etc etc ...] can be more than one merge\n base for a pair of commits.\n\n OPERATION MODE\n --------------\n As the most common special case, specifying only two commits on the\n command line means computing the merge base between the given two\n commits.\n\n More generally, among the two commits to compute the merge base from,\n one is specified by the first commit argument on the command line;\n the other commit is a (possibly hypothetical) commit that is a merge\n across all the remaining commits on the command line.\n\n As a consequence, the merge base is not necessarily contained in each\n of the commit arguments if more than two commits are specified.\n This is different from git-show-branch(1) when used with\n the --merge-base option.\n\n --octopus::\n\tCompute the best common ancestors of all supplied commits, in\n\tpreparation for an n-way merge.\n\tThis mimics the behavior of 'git show-branch --merge-base'.\n\n --independent::\n\tInstead of ...\n\n OPTIONS\n -------\n -a::\n --all::\n\t...\n\n DISCUSSION\n ----------\n\nWhat do you think?\n\n> --- a/Documentation/git-merge-base.txt\n> +++ b/Documentation/git-merge-base.txt\n> @@ -9,7 +9,8 @@ git-merge-base - Find as good common ancestors as possible for a merge\n[...]\n> +When the option `--octopus` is given, the result of `git merge-base A B C`\n> +will be '2', because '2' is the common ancestor of all branches.\n> +\n\nFor what it's worth, except for Junio's wording nitpick and the log message,\nReviewed-by: Jonathan Nieder <jrnieder@gmail.com>\n\nThanks.\n"},{"id":"165888","messageId":"4DA802FB.7040506@lyx.org","threadId":"27074","inReplyTo":"4DA47A4D.80909@lyx.org","subject":"[PATCH v2 1/2] Documentation: update to git-merge-base --octopus","fromName":"Vincent van Ravesteijn","fromEmail":"vfr@lyx.org","sentAt":"2011-04-15T08:34:03Z","receivedAt":"2011-04-15T08:34:03Z","isPatch":true,"sender":{"key":"vfr@lyx.org","avatar":"https://avatars.githubusercontent.com/u/687868?v=4"},"body":"1) Unlike plain merge-base, merge-base --octopus only requires at least one commit\nargument, and this patch updates the synopsis to reflect that.\n\n2) Add a sentence to the discussion that when --octopus is used, we do expect '2'\nas the result.\n\nSigned-off-by: Vincent van Ravesteijn <vfr@lyx.org>\nReviewed-by: Jonathan Nieder <jrnieder@gmail.com>\n---\n Documentation/git-merge-base.txt |    6 +++++-\n builtin/merge-base.c             |    3 ++-\n 2 files changed, 7 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt\nindex eedef1b..a9f677b 100644\n--- a/Documentation/git-merge-base.txt\n+++ b/Documentation/git-merge-base.txt\n@@ -9,7 +9,8 @@ git-merge-base - Find as good common ancestors as possible for a merge\n SYNOPSIS\n --------\n [verse]\n-'git merge-base' [-a|--all] [--octopus] <commit> <commit>...\n+'git merge-base' [-a|--all] <commit> <commit>...\n+'git merge-base' [-a|--all] --octopus <commit>...\n 'git merge-base' --independent <commit>...\n\n DESCRIPTION\n@@ -89,6 +90,9 @@ and the result of `git merge-base A M` is '1'.  Commit '2' is also a\n common ancestor between 'A' and 'M', but '1' is a better common ancestor,\n because '2' is an ancestor of '1'.  Hence, '2' is not a merge base.\n\n+The result of `git merge-base --octopus A B C` is '2', because '2' is\n+the best common ancestor of all commits.\n+\n When the history involves criss-cross merges, there can be more than one\n 'best' common ancestor for two commits.  For example, with this topology:\n\ndiff --git a/builtin/merge-base.c b/builtin/merge-base.c\nindex 96dd160..4f30f1b 100644\n--- a/builtin/merge-base.c\n+++ b/builtin/merge-base.c\n@@ -23,7 +23,8 @@ static int show_merge_base(struct commit **rev, int rev_nr, int show_all)\n }\n\n static const char * const merge_base_usage[] = {\n-\t\"git merge-base [-a|--all] [--octopus] <commit> <commit>...\",\n+\t\"git merge-base [-a|--all] <commit> <commit>...\",\n+\t\"git merge-base [-a|--all] --octopus <commit>...\",\n \t\"git merge-base --independent <commit>...\",\n \tNULL\n };\n-- \n1.7.3.1.msysgit.0\n"},{"id":"165889","messageId":"4DA8041F.3090502@lyx.org","threadId":"27074","inReplyTo":"4DA47A4D.80909@lyx.org","subject":"[PATCH 2/2] Restructure documentation for git-merge-base.","fromName":"Vincent van Ravesteijn","fromEmail":"vfr@lyx.org","sentAt":"2011-04-15T08:38:55Z","receivedAt":"2011-04-15T08:38:55Z","isPatch":true,"sender":{"key":"vfr@lyx.org","avatar":"https://avatars.githubusercontent.com/u/687868?v=4"},"body":"From: Jonathan Nieder <jrnieder@gmail.com>\n\nRestructure the text of git-merge-base to better explain more clearly\nthe different modes of operation.\n\nSigned-off-by: Vincent van Ravesteijn <vfr@lyx.org>\n\n---\n Documentation/git-merge-base.txt |   28 ++++++++++++++++------------\n 1 files changed, 16 insertions(+), 12 deletions(-)\n\ndiff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt\nindex a9f677b..ca5ed31 100644\n--- a/Documentation/git-merge-base.txt\n+++ b/Documentation/git-merge-base.txt\n@@ -23,23 +23,21 @@ that does not have any better common ancestor is a 'best common\n ancestor', i.e. a 'merge base'.  Note that there can be more than one\n merge base for a pair of commits.\n\n-Unless `--octopus` is given, among the two commits to compute the merge\n-base from, one is specified by the first commit argument on the command\n-line; the other commit is a (possibly hypothetical) commit that is a merge\n-across all the remaining commits on the command line.  As the most common\n-special case, specifying only two commits on the command line means\n-computing the merge base between the given two commits.\n+OPERATION MODE\n+--------------\n+\n+As the most common special case, specifying only two commits on the\n+command line means computing the merge base between the given two commits.\n+\n+More generally, among the two commits to compute the merge base from,\n+one is specified by the first commit argument on the command line;\n+the other commit is a (possibly hypothetical) commit that is a merge\n+across all the remaining commits on the command line.\n\n As a consequence, the 'merge base' is not necessarily contained in each of the\n commit arguments if more than two commits are specified. This is different\n from linkgit:git-show-branch[1] when used with the `--merge-base` option.\n\n-OPTIONS\n--------\n--a::\n---all::\n-\tOutput all merge bases for the commits, instead of just one.\n-\n --octopus::\n \tCompute the best common ancestors of all supplied commits,\n \tin preparation for an n-way merge.  This mimics the behavior\n@@ -52,6 +50,12 @@ OPTIONS\n \tfrom any other.  This mimics the behavior of 'git show-branch\n \t--independent'.\n\n+OPTIONS\n+-------\n+-a::\n+--all::\n+\tOutput all merge bases for the commits, instead of just one.\n+\n DISCUSSION\n ----------\n\n-- \n1.7.3.1.msysgit.0\n"},{"id":"165890","messageId":"4DA80549.5040600@lyx.org","threadId":"27074","inReplyTo":"20110412194558.GB1209@elie","subject":"Re: [PATCH/resend] Documentation: update to git-merge-base --octopus","fromName":"Vincent van Ravesteijn","fromEmail":"vfr@lyx.org","sentAt":"2011-04-15T08:43:53Z","receivedAt":"2011-04-15T08:43:53Z","isPatch":true,"sender":{"key":"vfr@lyx.org","avatar":"https://avatars.githubusercontent.com/u/687868?v=4"},"body":">> +When the option `--octopus` is given, the result of `git merge-base A B C`\n>> > +will be '2', because '2' is the common ancestor of all branches.\n> \n> Wouldn't it be easier to read if you had the option in the command line, i.e.\n> \n>     The result of `git merge-base --octopus A B C` is '2' because...\n> \n> without \"When ... given\" that now become noisewords?\n\nYes, that's much better. I included it in the rerolled patch series.\n\n> Adding an example use of --octopus to the DISCUSSION section makes a\n> lot of sense.  At first I thought this was being added to the\n> DESCRIPTION section, which led me to suggest something like the\n> following:\n> \n> [..]\n> \n> What do you think?\n\nI like it, so I made a patch out of it and sent it to the list.\n\n> For what it's worth, except for Junio's wording nitpick and the log message,\n> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>\n\nThanks,\n\nVincent\n"},{"id":"165910","messageId":"7v39lje8mp.fsf@alter.siamese.dyndns.org","threadId":"27074","inReplyTo":"4DA80549.5040600@lyx.org","subject":"Re: [PATCH/resend] Documentation: update to git-merge-base --octopus","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-15T17:18:06Z","receivedAt":"2011-04-15T17:18:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Vincent van Ravesteijn <vfr@lyx.org> writes:\n\n>>> +When the option `--octopus` is given, the result of `git merge-base A B C`\n>>> > +will be '2', because '2' is the common ancestor of all branches.\n>> \n>> Wouldn't it be easier to read if you had the option in the command line, i.e.\n>> \n>>     The result of `git merge-base --octopus A B C` is '2' because...\n>> \n>> without \"When ... given\" that now become noisewords?\n>\n> Yes, that's much better. I included it in the rerolled patch series.\n\nMakes sense.  Will queue both patches.\n\nThanks, both.\n"}]}