I think you’re maybe not getting what I want - unless I’m misunderstanding, the three way diff you suggest won’t work for this. In the simplest possible config

I think you’re maybe not getting what I want - unless I’m misunderstanding, the three way diff you suggest won’t work for this. In the simplest possible configuration that exhibits the pattern, there are commits like this … - A - B - C. To revert A cleanly, C must first be reverted because it changes code also changed in A. B touches a different part of the code and so doesn’t need to be reverted. Factor in a few days worth of commits from a large team, and it’s easy to see how very complex trees (even graphs, I think, so long as all the dependencies point backwards) can appear. But it _is_ always possible to get a minimal ordered chain of clean reverts that are required to revert A and all its dependencies. It’s definitely true that, as you say, things might have knock-on effects - like, perhaps there no textual dependency from B to A, but the logic is very much dependent. Thorough testing of the results is needed. But in a large well-factored project the chances of things being fine when an entire dependency chain is reverted are (in my experience doing things like this) surprisingly high.