Sergey Organov <sorganov@xxxxxxxxx> writes: > Vanilla "git rebase" defaults to --fork-point that in some cases > makes behavior very different from "git rebase <upstream>", > where --no-fork-point is assumed. This fact was not mentioned in > the DESCRIPTION section of the manual page, even though the case of > omitted <upstream> was otherwise discussed. That in turn made actual > behavior of vanilla "git rebase" hardly discoverable. > > While we are at it, clarify the --fork-point description itself as well. > > Signed-off-by: Sergey Organov <sorganov@xxxxxxxxx> > --- > As asked by Junio C Hamano <gitster@xxxxxxxxx>, the newly introduced > 'fork_point' term has been described. > I suspect "will be used as a fallback" might be easier to understand what is going on instead of "will be used instead", but other than that, the new explanation of what fork-point is is a very welcome update, I think. > diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt > index 4138554..2e6f125 100644 > --- a/Documentation/git-rebase.txt > +++ b/Documentation/git-rebase.txt > @@ -21,15 +21,17 @@ If <branch> is specified, 'git rebase' will perform an automatic > it remains on the current branch. > > If <upstream> is not specified, the upstream configured in > +branch.<name>.remote and branch.<name>.merge options will be used (see > +linkgit:git-config[1] for details) and the `--fork-point` option is > +assumed. If you are currently not on any branch or if the current > +branch does not have a configured upstream, the rebase will abort. > > All changes made by commits in the current branch but that are not > in <upstream> are saved to a temporary area. This is the same set > +of commits that would be shown by `git log <upstream>..HEAD`; or by > +`git log 'fork_point'..HEAD`, if --fork-point is either specified or > +assumed (see --fork-point description below); or by `git log HEAD`, if > +--root is specified. It is easier to read with "is either specified or assumed" shortened to "is active", I think, because that is the word you use to explain how the commit is computed for --fork-point processing. > @@ -327,13 +329,18 @@ > link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] > for details) > > --fork-point:: > --no-fork-point:: > + Use reflog to find a better common ancestor between <upstream> > + and <branch> when calculating which commits have been > + introduced by <branch>. > + > +When --fork-point is active, 'fork_point' will be used instead of > +<upstream> to calculate the set of commits to rebase, where > +'fork_point' is the result of `git merge-base --fork-point <upstream> > +<branch>` command (see linkgit:git-merge-base[1]). If 'fork_point' > +ends up being empty, the <upstream> will be used instead. > ++ > +If either <upstream> or --root is given on the command line, then the > +default is `--no-fork-point`, otherwise the default is `--fork-point`. > > --ignore-whitespace:: > --whitespace=<option>:: The patch failed to apply Applying: Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla "git rebase" in DESCRIPTION. fatal: corrupt patch at line 38 but the fix-up is trivial, so no need to resend. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html