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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Sep 16, 2025, 22:14 UTC
Message-ID: <aMnhSm5QSdRwiJds@fruit.crustytoothpaste.net>
In-Reply-To: <CACEPZDXGGn0S_8PpEc=BVHhvyuZhWfiDmbxNOK7iPWJOj1jrXg@mail.gmail.com>

On 2025-09-16 at 21:39:46, Antonio Mennillo wrote:

> Hi Git community,

Hi,

Show 9 quoted lines

> 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.

Show 5 quoted lines

> 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.

Show 7 quoted lines

> 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