Re: [PATCH v4] doc: git-rebase: update incompatible options

[Tuomas Ahola <taahol@utu.fi>]

[administrivia]
  Please send subsequent rerolls as direct replies to the v4 patch message
  (git send-email --in-reply-to= ).

Omri Sarig <omri.sarig13@gmail.com> wrote:

> A few options in the rebase manual page link to the "INCOMPATIBLE
> OPTIONS" section, but they are no longer incompatible with any other
> option:
> - Commit 1a66d8c6f6 (rebase: remove --allow-empty-message from
>   incompatible opts, 2023-01-25) removed "--allow-empty-message" from
>   the INCOMPATIBLE OPTIONS section, but did not remove the link to that
>   section from the option description.
> - Commit a74b35081c (rebase: drop support for `--preserve-merges`,
>   2021-09-07) removed the `--preserve-merges` option from rebase, which
>   removes all incompatibility references to `--ignore-date,
>   --reset-author-date` and `--signoff`.
> 

Okay.  "INCOMPATIBLE OPTIONS" says nothing about "--allow-empty-message",
"--ignore-date", "--reset-author-date", and "--signoff", so links from those
sections to incomp opts have to go.

Well observed!

> Additionally, since 414d924beb (rebase: teach rebase --keep-base,
> 2019-08-27) the `--onto` option is incompatible with `--keep-base`, but
> it is not mentioned in the INCOMPATIBLE OPTIONS section.
> 

"--onto" is mentioned in incomp opts, but the description doesn't link there.

Just steal the correct wording from the v3 where you had it already right. :-)

> Update the description of these options, to have correct references to
> the INCOMPATIBLE OPTIONS section.
> 
> Signed-off-by: Omri Sarig <omri.sarig13@gmail.com>
> ---
> 
> Thank you for the review!
> 
> Changes in V2:
> - Update commit message per the review comments from Phillip (Thanks for the
>   review!).
> - Add `--onto` to INCOMPATIBLE OPTIONS.
> 
> Changes in V3:
> - Downcase "Update" in commit title
> 
> Changes in V4:
> - Update the commit message per review comments.
> - Rebase the patch to be compatible with the maint branch.
> 
> The main difference in git-rebase.adoc between the maintenance branch and the
> main branch was created in 2fc11e3382 (doc: add more AsciiDoc cross-references,
> 2026-09-25), which turned all the "See also..." lines into links. This created
> conflicts with the removed lines, which I've solved.
> I was not sure what is the correct way to add the new INCOMPATIBLE OPTION line
> in this patch. As I see it, this line can be aligned with the current version
> of the file (without the link), or "correct" for the final version of the file
> (with the link). Here, I opted to adding this line in the aligned form for the
> maintenance branch. This will require some work when merging this change to the
> main branch, as this new line will have to be updated.

Excellent!  The patch now applies cleanly to 'maint'.  When this topic has
settled down (i.e. merged to 'next'), you would perhaps like to send a followup
patch as a separate topic.  Such patch would look something like this, if you are
interested:


diff --git a/Documentation/git-rebase.adoc b/Documentation/git-rebase.adoc
index 6190479966..e9c463da57 100644
--- a/Documentation/git-rebase.adoc
+++ b/Documentation/git-rebase.adoc
@@ -216,13 +216,13 @@ OPTIONS
 	existing branch name.
 +
 As a special case, you may use "A\...B" as a shortcut for the
 merge base of A and B if there is exactly one merge base. You can
 leave out at most one of A and B, in which case it defaults to HEAD.
 +
-See also INCOMPATIBLE OPTIONS below.
+See also <<INCOMPATIBLE_OPTIONS,INCOMPATIBLE OPTIONS>> below.
 
 See <<TRANSPLANTING,TRANSPLANTING A TOPIC BRANCH WITH --ONTO>>
 above for examples.
 
 --keep-base::
 	Set the starting point at which to create the new commits to the
@@ -497,13 +497,13 @@ applying (in terms of the author date).
 
 --trailer=<trailer>::
 	Append the given trailer to every rebased commit message, processed
 	via linkgit:git-interpret-trailers[1]. This option implies
 	`--force-rebase`.
 +
-See also INCOMPATIBLE OPTIONS below.
+See also <<INCOMPATIBLE_OPTIONS,INCOMPATIBLE OPTIONS>> below.
 
 -i::
 --interactive::
 	Make a list of the commits which are about to be rebased.  Let the
 	user edit that list before rebasing.  This mode can also be used to
 	split commits (see <<SPLITTING_COMMITS,SPLITTING COMMITS>> below).


> I was not sure if this is the correct strategy. If the right way to do it, is
> to add the "final" version of the line, please let me know, and I'll provide a
> V5.
> 
> Thank you for the support in helping me get this through.
> 
>  Documentation/git-rebase.adoc | 8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/git-rebase.adoc b/Documentation/git-rebase.adoc
> index f6c22d1598..f1f675d311 100644
> --- a/Documentation/git-rebase.adoc
> +++ b/Documentation/git-rebase.adoc
> @@ -217,6 +217,8 @@ OPTIONS
>  As a special case, you may use "A\...B" as a shortcut for the
>  merge base of A and B if there is exactly one merge base. You can
>  leave out at most one of A and B, in which case it defaults to HEAD.
> ++
> +See also INCOMPATIBLE OPTIONS below.
>  
>  See TRANSPLANTING A TOPIC BRANCH WITH --ONTO above for examples.
>  
> @@ -332,8 +334,6 @@ See also INCOMPATIBLE OPTIONS below.
>  	and this option would override that behavior, allowing commits
>  	with empty messages to be rebased.  Now commits with an empty
>  	message do not cause rebasing to halt.
> -+
> -See also INCOMPATIBLE OPTIONS below.
>  
>  -m::
>  --merge::
> @@ -487,15 +487,11 @@ applying (in terms of the author date).
>  	Instead of using the author date of the original commit, use
>  	the current time as the	author date of the rebased commit.  This
>  	option implies `--force-rebase`.
> -+
> -See also INCOMPATIBLE OPTIONS below.
>  
>  --signoff::
>  	Add a `Signed-off-by` trailer to all the rebased commits. Note
>  	that if `--interactive` is given then only commits marked to be
>  	picked, edited or reworded will have the trailer added.
> -+
> -See also INCOMPATIBLE OPTIONS below.
>  
>  --trailer=<trailer>::
>  	Append the given trailer to every rebased commit message, processed

The changes are good to go, but see my nit for the commit log message.

--Tuomas