Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > Hi Nicolas > > On 09/10/2024 08:58, Nicolas Guichard via GitGitGadget wrote: >> From: Nicolas Guichard <nicolas@xxxxxxxxxxx> >> 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.
