From: Phillip Wood <phillip.wood123@gmail.com>
Date: Tue, 21 Feb 2023 11:01:38 GMT
Subject: Re: [PATCH v2 1/4] rebase: document the --no-rebase-merges option
Message-ID: <f67126c0-82d3-bbec-89e8-fbe3ec84e04b@dunelm.org.uk>
In-Reply-To: <20230221055805.210951-1-alexhenrie24@gmail.com>

Hi Alex

Thanks for working on this series, I think it is going in a sensible 
direction. I think the final patch needs a little bit of work but 
they're all looking good.

Best Wishes

Phillip

On 21/02/2023 05:58, Alex Henrie wrote:
> Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
> ---
>   Documentation/git-rebase.txt | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index 9a295bcee4..c98784a0d2 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -529,13 +529,15 @@ See also INCOMPATIBLE OPTIONS below.
>   
>   -r::
>   --rebase-merges[=(rebase-cousins|no-rebase-cousins)]::
> +--no-rebase-merges::
>   	By default, a rebase will simply drop merge commits from the todo
>   	list, and put the rebased commits into a single, linear branch.
>   	With `--rebase-merges`, the rebase will instead try to preserve
>   	the branching structure within the commits that are to be rebased,
>   	by recreating the merge commits. Any resolved merge conflicts or
>   	manual amendments in these merge commits will have to be
> -	resolved/re-applied manually.
> +	resolved/re-applied manually. `--no-rebase-merges` can be used to
> +	countermand a previous `--rebase-merges`.
>   +
>   By default, or when `no-rebase-cousins` was specified, commits which do not
>   have `<upstream>` as direct ancestor will keep their original branch point,