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

From: "brian m. carlson" <[email-masked]>
Date: Tue, 16 Sep 2025 22:14:34 +0000

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