| Message ID | ab2367594a3267a5f8d01cdfdcba576f286e3823.1628004920.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Documentation updates: merge-strategies | expand |
Hi Elijah, On Tue, 3 Aug 2021, Elijah Newren via GitGitGadget wrote: > From: Elijah Newren <newren@gmail.com> > > When --rebase-merges was first introduced, it only worked with the > `recursive` strategy. Some time later, it gained support for merges > using the `octopus` strategy. The limitation of only supporting these > two strategies was documented in 25cff9f109 ("rebase -i --rebase-merges: > add a section to the man page", 2018-04-25) and lifted in e145d99347 > ("rebase -r: support merge strategies other than `recursive`", > 2019-07-31). However, when the limitation was lifted, the documentation > was not updated. Update it now. ACK! Thank you, Dscho > > Signed-off-by: Elijah Newren <newren@gmail.com> > --- > Documentation/git-rebase.txt | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt > index 55af6fd24e2..8a67227846a 100644 > --- a/Documentation/git-rebase.txt > +++ b/Documentation/git-rebase.txt > @@ -1219,12 +1219,16 @@ successful merge so that the user can edit the message. > If a `merge` command fails for any reason other than merge conflicts (i.e. > when the merge operation did not even start), it is rescheduled immediately. > > -At this time, the `merge` command will *always* use the `recursive` > -merge strategy for regular merges, and `octopus` for octopus merges, > -with no way to choose a different one. To work around > -this, an `exec` command can be used to call `git merge` explicitly, > -using the fact that the labels are worktree-local refs (the ref > -`refs/rewritten/onto` would correspond to the label `onto`, for example). > +By default, the `merge` command will use the `recursive` merge > +strategy for regular merges, and `octopus` for octopus merges. One > +can specify a default strategy for all merges using the `--strategy` > +argument when invoking rebase, or can override specific merges in the > +interactive list of commands by using an `exec` command to call `git > +merge` explicitly with a `--strategy` argument. Note that when > +calling `git merge` explicitly like this, you can make use of the fact > +that the labels are worktree-local refs (the ref `refs/rewritten/onto` > +would correspond to the label `onto`, for example) in order to refer > +to the branches you want to merge. > > Note: the first command (`label onto`) labels the revision onto which > the commits are rebased; The name `onto` is just a convention, as a nod > -- > gitgitgadget > >
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 55af6fd24e2..8a67227846a 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -1219,12 +1219,16 @@ successful merge so that the user can edit the message. If a `merge` command fails for any reason other than merge conflicts (i.e. when the merge operation did not even start), it is rescheduled immediately. -At this time, the `merge` command will *always* use the `recursive` -merge strategy for regular merges, and `octopus` for octopus merges, -with no way to choose a different one. To work around -this, an `exec` command can be used to call `git merge` explicitly, -using the fact that the labels are worktree-local refs (the ref -`refs/rewritten/onto` would correspond to the label `onto`, for example). +By default, the `merge` command will use the `recursive` merge +strategy for regular merges, and `octopus` for octopus merges. One +can specify a default strategy for all merges using the `--strategy` +argument when invoking rebase, or can override specific merges in the +interactive list of commands by using an `exec` command to call `git +merge` explicitly with a `--strategy` argument. Note that when +calling `git merge` explicitly like this, you can make use of the fact +that the labels are worktree-local refs (the ref `refs/rewritten/onto` +would correspond to the label `onto`, for example) in order to refer +to the branches you want to merge. Note: the first command (`label onto`) labels the revision onto which the commits are rebased; The name `onto` is just a convention, as a nod