Re: [PATCH v5 1/3] rebase: add documentation and test for --no-rebase-merges
From: Glen Choo <hidden>
Date: 2023-03-01 23:24:09
Alex Henrie [off-list ref] writes:
Signed-off-by: Alex Henrie <redacted>
I inferred from the 'subject line' that this "always" worked and was undocumented, and that we'd want to document this not for its own sake, but because we'll introduce a config option. I would personally prefer to get that explicitly in writing, but it's definitely not worth a reroll.
quoted hunk ↗ jump to hunk
-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,diff --git a/t/t3430-rebase-merges.sh b/t/t3430-rebase-merges.sh
This isn't the fault of this patch, but I find this description a little confusing. First we say By default (*when no option is given*), a rebase will simply drop merge commits from the todo list... and then later we also say By default (*when --rebase-merges is provided without a value), or when `no-rebase-cousins`... So although you didn't create this problem, given the changes we're making in the later patches, I think we have the chance to make this description more sensible; I'll elaborate in my response to those patches.