Re: [PATCH v3 3/3] rebase-merges: try and use branch names as labels

Phillip Wood [off-list ref] writes:

Hi Nicolas

On 09/10/2024 08:58, Nicolas Guichard via GitGitGadget wrote:

quoted

From: Nicolas Guichard <redacted>
When interactively rebasing merge commits, the commit message is
parsed to
extract a probably meaningful label name. For instance if the merge commit
is “Merge branch 'feature0'”, then the rebase script will have thes lines:

label feature0
merge -C $sha feature0 # “Merge branch 'feature0'

This heuristic fails in the case of octopus merges or when the merge
commit
message is actually unrelated to the parent commits.
An example that combines both is:

*---.   967bfa4 (HEAD -> integration) Integration
|\ \ \
| | | * 2135be1 (feature2, feat2) Feature 2
| |_|/
|/| |
| | * c88b01a Feature 1
| |/
|/|
| * 75f3139 (feat0) Feature 0
|/
* 25c86d0 (main) Initial commit

yields the labels Integration, Integration-2 and Integration-3.
Fix this by using a branch name for each merge commit's parent that
is the
tip of at least one branch, and falling back to a label derived from the
merge commit message otherwise.
In the example above, the labels become feat0, Integration and feature2.

This looks like a nicely described useful improvement, thank you for
working on it. The way the code is structured means we always
calculate the fallback label before seeing if there is a branch name
we could use instead but as calculating the fallback is cheap I don't
think that's a problem in practice.

Thanks, both of you.

Will queue.