[barneygale]

> For example, say A is a patch that renames the function foo() to foobar()

Why are you allowing commits to land that break interfaces?

If this is a public function it should go through a deprecation cycle.

If this is a private function then it shouldn't be accessed from outside its module/class/whatever in the first place. If it is, then you've got the "messy codebase" I referred to in my original comment.

[aseipp]

They can both be private methods in a single module, the example still applies fine? You can for example rename a private function in a single rust crate, which is used by other functions within the crate, which is not exported.

I'm not sure if you're being intentionally obtuse here, it's a very simple scenario that has nothing to do with public interfaces or deprecation cycles.

[barneygale]

> They can both be private methods in a single module, the example still applies fine?

It does, but you're now looking at an edge case that rarely arises in practice in a well-maintained codebase, and certainly not one to design your entire branching/merging/CI strategy around.

If your codebase is a spaghettified nonsense then the problem arises much more often, and so I can understand the use of merge trains/whatnot.

[plonk]

My situation: small team with around 10 simultaneous projects at any one time, all depending on a framework that we use for tons of different things. Everyone is constantly modifying the same parts of the code because that’s where the features should be added. It’s way cleaner than when the projects were separated and didn’t share code.

In this case, we often have conflicts in private modules. (And everything is private since we don’t provide any libraries to anyone.)