Documentation: update to git-merge-base --octopus
1) Make it clear that when the --octopus parameter is given to 'git merge-base', only a set of commits is expected as the parameter. On the other hand, in the case without the --octopus parameter, it is necessary to supply a single commit and a set. Moreover, in the case of --octopus merging, a single commit is also valid, which is not the case otherwise.
2) Add a sentence to the discussion that when --octopus is used, we do expect '2' as the result.
---
Sorry for the noise caused by the previous attempt(s). Apparently my attempts to let Thunderbird _not wrap_ the lines were counterproductive.
Here is the patch again.
Documentation/git-merge-base.txt | 6 +++++- builtin/merge-base.c | 3 ++- 2 files changed, 7 insertions(+), 2 deletions(-)
Documentation/git-merge-base.txt +5 -1
@@ -9,7 +9,8 @@ git-merge-base - Find as good common ancestors as possible for a merge SYNOPSIS -------- [verse] -'git merge-base' [-a|--all] [--octopus] <commit> <commit>... +'git merge-base' [-a|--all] <commit> <commit>... +'git merge-base' [-a|--all] --octopus <commit>... 'git merge-base' --independent <commit>... DESCRIPTION
@@ -89,6 +90,9 @@ and the result of `git merge-base A M` is '1'. Commit '2' is also a common ancestor between 'A' and 'M', but '1' is a better common ancestor, because '2' is an ancestor of '1'. Hence, '2' is not a merge base. +When the option `--octopus` is given, the result of `git merge-base A B C` +will be '2', because '2' is the common ancestor of all branches. + When the history involves criss-cross merges, there can be more than one 'best' common ancestor for two commits. For example, with this topology:
builtin/merge-base.c +2 -1
@@ -23,7 +23,8 @@ static int show_merge_base(struct commit **rev, int rev_nr, int show_all) }static const char *const merge_base_usage[] = { -"git merge-base [-a|--all] [--octopus] <commit> <commit>..." , +"git merge-base [-a|--all] <commit> <commit>..." , +"git merge-base [-a|--all] --octopus <commit>..." ,"git merge-base --independent <commit>..." ,NULL };
Signature · 1 line
1.7.3.1.msysgit.0
Jonathan Nieder
Reviewed-byHi Vincent,
Quoted 4 lines · Vincent van Ravesteijn
On the other hand, in the
case without the --octopus parameter, it is necessary to supply a single commit and a set. Moreover, in the case of --octopus merging, a single commit is also valid, which is not the case otherwise.
So to summarize: unlike plain merge-base, merge-base --octopus only requires at least one commit argument, and this patch updates the synopsis to reflect that. Good catch.
Quoted 2 lines
2) Add a sentence to the discussion that when --octopus is used, we do expect '2' as the result.
Adding an example use of --octopus to the DISCUSSION section makes a lot of sense. At first I thought this was being added to the DESCRIPTION section, which led me to suggest something like the following:
DESCRIPTION
-----------
'git merge-base' finds best common ancestors between two commits to use in a three-way merge. [... etc etc ...] can be more than one merge base for a pair of commits.
OPERATION MODE
--------------
As the most common special case, specifying only two commits on the command line means computing the merge base between the given two commits.
More generally, among the two commits to compute the merge base from, one is specified by the first commit argument on the command line; the other commit is a (possibly hypothetical) commit that is a merge across all the remaining commits on the command line.
As a consequence, the merge base is not necessarily contained in each of the commit arguments if more than two commits are specified. This is different from git-show-branch(1) when used with the --merge-base option.
--octopus::
Compute the best common ancestors of all supplied commits, in preparation for an n-way merge.
This mimics the behavior of 'git show-branch --merge-base'.
--independent::
Instead of ...
OPTIONS
-------
-a::
--all::
...
DISCUSSION
----------
What do you think?
Quoted 3 lines
Documentation/git-merge-base.txt +0
-0@@ -9,7 +9,8 @@ git-merge-base - Find as good common ancestors as possible for a merge
[...]
Documentation/git-merge-base.txt and the result of `git merge-base A M` is '1'. Commit '2' is also a · line 95
Quoted 3 lines
Documentation/git-merge-base.txt +3
-0+When the option `--octopus` is given, the result of `git merge-base A B C` +will be '2', because '2' is the common ancestor of all branches. +
For what it's worth, except for Junio's wording nitpick and the log message,
Thanks.
Quoted 8 lines
Quoted 2 lines
+When the option
--octopusis given, the result ofgit merge-base A B CQuoted 1 line
+will be '2', because '2' is the common ancestor of all branches.
Wouldn't it be easier to read if you had the option in the command line, i.e.
The result of
git merge-base --octopus A B Cis '2' because...without "When ... given" that now become noisewords?
Yes, that's much better. I included it in the rerolled patch series.
Quoted 8 lines
Adding an example use of --octopus to the DISCUSSION section makes a lot of sense. At first I thought this was being added to the DESCRIPTION section, which led me to suggest something like the following:
[..]
What do you think?
I like it, so I made a patch out of it and sent it to the list.
Quoted 2 lines
For what it's worth, except for Junio's wording nitpick and the log message,
Reviewed-by Jonathan Nieder <[email protected]>
Thanks,
Vincent
Quoted 10 lines · Vincent van Ravesteijn
Quoted 8 lines
Quoted 2 lines
+When the option
--octopusis given, the result ofgit merge-base A B CQuoted 1 line
+will be '2', because '2' is the common ancestor of all branches.
Wouldn't it be easier to read if you had the option in the command line, i.e.
The result of
git merge-base --octopus A B Cis '2' because...without "When ... given" that now become noisewords?
Yes, that's much better. I included it in the rerolled patch series.
Makes sense. Will queue both patches.
Thanks, both.
PATCH v2 1/2 Documentation: update to git-merge-base --octopus
In reply to Vincent van Ravesteijn1) Unlike plain merge-base, merge-base --octopus only requires at least one commit argument, and this patch updates the synopsis to reflect that.
2) Add a sentence to the discussion that when --octopus is used, we do expect '2' as the result.
--- Documentation/git-merge-base.txt | 6 +++++- builtin/merge-base.c | 3 ++- 2 files changed, 7 insertions(+), 2 deletions(-)
Documentation/git-merge-base.txt +5 -1
@@ -9,7 +9,8 @@ git-merge-base - Find as good common ancestors as possible for a merge SYNOPSIS -------- [verse] -'git merge-base' [-a|--all] [--octopus] <commit> <commit>... +'git merge-base' [-a|--all] <commit> <commit>... +'git merge-base' [-a|--all] --octopus <commit>... 'git merge-base' --independent <commit>... DESCRIPTION
@@ -89,6 +90,9 @@ and the result of `git merge-base A M` is '1'. Commit '2' is also a common ancestor between 'A' and 'M', but '1' is a better common ancestor, because '2' is an ancestor of '1'. Hence, '2' is not a merge base. +The result of `git merge-base --octopus A B C` is '2', because '2' is +the best common ancestor of all commits. + When the history involves criss-cross merges, there can be more than one 'best' common ancestor for two commits. For example, with this topology:
builtin/merge-base.c +2 -1
@@ -23,7 +23,8 @@ static int show_merge_base(struct commit **rev, int rev_nr, int show_all) }static const char *const merge_base_usage[] = { -"git merge-base [-a|--all] [--octopus] <commit> <commit>..." , +"git merge-base [-a|--all] <commit> <commit>..." , +"git merge-base [-a|--all] --octopus <commit>..." ,"git merge-base --independent <commit>..." ,NULL };
Signature · 1 line
1.7.3.1.msysgit.0
PATCH 2/2 Restructure documentation for git-merge-base.
In reply to Vincent van RavesteijnFrom: Jonathan Nieder <[email protected]>
Restructure the text of git-merge-base to better explain more clearly the different modes of operation.
--- Documentation/git-merge-base.txt | 28 ++++++++++++++++------------ 1 files changed, 16 insertions(+), 12 deletions(-)
Documentation/git-merge-base.txt +16 -12
@@ -23,23 +23,21 @@ that does not have any better common ancestor is a 'best common ancestor', i.e. a 'merge base'. Note that there can be more than one merge base for a pair of commits. -Unless `--octopus` is given, among the two commits to compute the merge -base from, one is specified by the first commit argument on the command -line; the other commit is a (possibly hypothetical) commit that is a merge -across all the remaining commits on the command line. As the most common -special case, specifying only two commits on the command line means -computing the merge base between the given two commits. +OPERATION MODE +-------------- + +As the most common special case, specifying only two commits on the +command line means computing the merge base between the given two commits. + +More generally, among the two commits to compute the merge base from, +one is specified by the first commit argument on the command line; +the other commit is a (possibly hypothetical) commit that is a merge +across all the remaining commits on the command line. As a consequence, the 'merge base' is not necessarily contained in each of the commit arguments if more than two commits are specified. This is different from linkgit:git-show-branch[1] when used with the `--merge-base` option. -OPTIONS -------- --a:: ---all:: - Output all merge bases for the commits, instead of just one. - --octopus:: Compute the best common ancestors of all supplied commits, in preparation for an n-way merge. This mimics the behavior
@@ -52,6 +50,12 @@ OPTIONS from any other. This mimics the behavior of 'git show-branch --independent'. +OPTIONS +------- +-a:: +--all:: + Output all merge bases for the commits, instead of just one. + DISCUSSION ----------
Signature · 1 line
1.7.3.1.msysgit.0
Quoted 2 lines · Vincent van Ravesteijn
Sorry for the noise caused by the previous attempt(s). Apparently my attempts to let Thunderbird
_notwrap_the lines were counterproductive.
I was wondering what that was about.
Documentation/git-merge-base.txt and the result of `git merge-base A M` is '1'. Commit '2' is also a · line 94
Quoted 2 lines
Documentation/git-merge-base.txt +2
-0+When the option `--octopus` is given, the result of `git merge-base A B C` +will be '2', because '2' is the common ancestor of all branches.
Wouldn't it be easier to read if you had the option in the command line, i.e.
The result of git merge-base --octopus A B C is '2' because...
without "When ... given" that now become noisewords?