From: Antonio Mennillo Date: Thu, 18 Sep 2025 17:02:59 GMT Subject: Re: [RFC] git-rebase-clean: mitigating a “semantic conflict cascade” during rebase Message-ID: In-Reply-To: Hi Brian, Thank you for the thoughtful response, and please excuse me if I am a bit clumsy — this is my first interaction with the Git community. > Usually we would recommend that each commit be atomic... I perfectly understand this best practice. In my context, working with many junior developers, it is not always possible to enforce atomic commits. In some “emergency” situations we squashed just to make progress, even if that meant losing granularity. Your explanation really helped me see things more clearly, and I appreciated the constructive (non-toxic) way you put it. > Are you familiar with `git rerere`?... Yes, rerere helps with repeated textual conflicts, but the scenario I worry about is semantic: if commit M changes an interface and commit N implements it, then changing M during rebase can make N semantically invalid. rerere cannot solve that — it remembers markers, but cannot understand that “this implementation no longer matches the interface.” > I think most people on this list will consider losing the history unacceptable... That feedback inspired me to improve the tool. Version 2.0.0 (literally born today, thanks to your comment) now works differently: 1. Temporarily squash the feature branch (so the rebase is effectively `1/1`) 2. Resolve conflicts once, with the full final context 3. Automatically re-expand the squash by replaying saved diffs, restoring the original commits (with new hashes, as expected in any rebase) In integration tests this preserves detailed history while avoiding cascading conflicts. All 23 tests currently pass (including empty commits, binary files, special characters, conflict abort/continue). Of course, real-world usage is still pending. This workflow essentially resolves conflicts with full context, then reconstructs granular history — a kind of “best of both worlds.” I would be very interested in whether the community sees this worth exploring as an **experimental rebase strategy** (something like `git rebase --squash-restore`), or if it overlaps with existing mechanisms I am not aware of. Code: https://github.com/anthem87/clean-rebase/tree/v2.0.0 Best regards, Antonio Antonio Il giorno mer 17 set 2025 alle ore 00:14 brian m. carlson ha scritto: > > On 2025-09-16 at 21:39:46, Antonio Mennillo wrote: > > Hi Git community, > > Hi, > > > 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 > > Usually we would recommend that each commit be atomic. That is, each > commit should compile and pass all of the tests, so commits 12–15 would > be part of commit 11. > > > 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. > > Are you familiar with `git rerere`? I have just done a complicated > rebase of this sort and it remembers resolutions for you so you don't > have to. > > > 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. > > I think most people on this list will consider losing the history > unacceptable, so I don't think this is a thing we'll want to encourage. > -- > brian m. carlson (they/them) > Toronto, Ontario, CA