Re: [RFC] git-rebase-clean: mitigating a “semantic conflict cascade” during rebase

Hi Brian, Elijah,

I need to acknowledge that my initial reasoning around this tool developed quite rapidly, driven both by enthusiasm for sharing results and by pressure from growing interest in my work network. Now, with more time to reflect, I can analyze your comments more rationally seeing all the implications.

The "semantic conflict" example should be considered only as a limiting use case I've seen in emergency situations. It was not intended as the definition of the tool, but my fault I set it up in the object of the mailing list. The actual purpose is to consolidate rebase conflicts into a single step (one-pass conflict resolution) via squash, ideally reducing the cardinality from N to 1. For instance, rebasing a 20-commit feature branch with 5 conflict points currently requires 5 separate git rebase --continue cycles. This tool consolidates those into a single resolution step, then aims to reconstruct the commits. On large codebases, such as multi-modular Java projects, managing a rebase in an IDE becomes significantly more manageable with one consolidated conflict rather than dozens, reducing both cognitive load and the chance of errors.

I fully understand and respect the importance of atomic commits. To be explicit, this tool:

- does not make non-atomic commits atomic
- does not guarantee bisectability
- does not replace developer discipline

It only reduces the number of conflict resolution iterations. Poor commit atomicity will still widely affect the number of conflicting files. The "temporal flattening" I mentioned earlier refers simply to this consolidation.

From a technical standpoint, I am developing a different approach that properly addresses the concerns you raised. This new implementation works directly with Git's internal structures to ensure deterministic behavior, specifically handling revert detection, intermediate-only conflicts, non-content conflicts, and attribution at appropriate granularity levels.

I'm targeting this weekend for a working implementation with integration test coverage.

The goal remains pragmatic: helping developers handle complex rebases more efficiently when dealing with real-world constraints. The consequence of a bad commit atomicity will still be there to be solved by a strict commit discipline.

What becomes easier is avoiding redundant conflict resolution cycles, while the consequences of poor commit atomicity remain unchanged as the Git philosophy rightly points out.

Best regards, Antonio