This message was deleted.

Currently, we only rebase B onto A in this case if needed (i.e. if B changes the same files as A) to save time on CI (as a rebase will trigger a new CI run). This means that in the case where B does not need to be rebased, it will include both commit messages, because GitHub's merge strategy is not smart enough to realize A is already in main. We are looking at ways to improve this by either taking more control over the merge, or by allowing users to specify that they would always want each PR rebased before merging.

Given this context, do you have any preference on how you'd want this to work?

My preference would be for the behavior to be consistent regardless of potential merge conflicts. That's both surprising and difficult to predict. Beyond consistency, I cant think of an instance where I'd want A's commit message in B (it doesn't introduce that behavior!). I'll probably go back to manually merging one-by-one via GitHub until this is improved, honestly. Having the messages end up like this makes reading the commit logs in our main branch pretty difficult. Thank you again for the context, and understood that you're balancing this work against a million other things that all need attention. We're loving Graphite at https://camus.energy/ and are always looking forward to new features and improvements as they appear in our world.