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

Hi Git community,

I’m Antonio Mennillo, a self-taught developer (6 years). I’d like to ask for technical feedback on a workflow issue I’ve observed during rebase, and share a small userland tool I wrote to mitigate it.

Problem (observation, possibly a known limitation rather than a bug): When rebasing feature branches whose commits are semantically interdependent, Git replays commits one by one. In practice this can trigger a cascading conflict, similar to a loop. Example:

 - Commit 1: add interface IUserService
 - Commit 6: add UserServiceImpl (depends on 1)
 - Commit 11: change IUserService signature
 - Commits 12–15: update implementation/tests to match

During rebase, conflicts may appear at 1 and again at 6/11, forcing the user to remember prior resolutions and reconstruct intent across commits. If I’m mischaracterizing the model, I’d appreciate a correction. I’m sharing this humbly to verify whether this is expected behavior or if there is prior art I should be aware of.

Mitigation (userland workflow): I built `git-rebase-clean`, which squashes the feature branch first and then rebases. This concentrates conflict resolution into a single atomic step with the full final context visible. The obvious trade-off is commit history granularity: you lose individual commits but gain atomic conflict resolution. In my experience this reduces repeated/conflicting resolutions across dependent commits.

Usage (data points):
- 5+ months in develop/UAT, used in production environment today the first time
- 30-40 feature branches processed
- High reduction in conflict-resolution time
- Only incidents observed: some IDEs (e.g., IntelliJ) occasionally
fail to load all conflict markers when many conflicts concentrate in
the single squashed commit, requiring fallback to command-line
resolution

Repository: https://github.com/anthem87/clean-rebase
License: GNU AGPL-3.0-or-later for v2.x (earlier tags remain MIT for
historical reasons)

Questions:
1) Is this "semantic dependency" pain point considered an expected
limitation of git rebase, or perhaps an inherent trade-off in the
design?
2) Would you see value in documenting this squash-then-rebase pattern
in Git's guidance (or `contrib/`), as one possible workaround?
3) Are there existing internals, extensions, or directions you
recommend for handling dependent commits more gracefully?

Context note (authorship & licensing): There has been growing interest around this tool after real-world use within my company. To avoid misunderstandings about authorship and usage rights, I transitioned new releases to GNU AGPL-3.0 while older tags remain MIT; my goal is to preserve clear attribution and set appropriate terms. If this licensing discussion is out of scope for the list, please disregard this note.

I’m happy to adapt the tool to community standards if there is interest. Thank you for Git and for your time.

Best regards, Antonio Mennillo Naples, Italy