From: "brian m. carlson" <sandals@crustytoothpaste•net>
To: Antonio Mennillo <antoniomennillo87@gmail•com>
Cc: git@vger•kernel.org
Subject: Re: [RFC] git-rebase-clean: mitigating a “semantic conflict cascade” during rebase
Date: Tue, 16 Sep 2025 22:14:34 +0000 [thread overview]
Message-ID: <aMnhSm5QSdRwiJds@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <CACEPZDXGGn0S_8PpEc=BVHhvyuZhWfiDmbxNOK7iPWJOj1jrXg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1878 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2025-09-16 22:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-16 21:39 [RFC] git-rebase-clean: mitigating a “semantic conflict cascade” during rebase Antonio Mennillo
2025-09-16 22:14 ` brian m. carlson [this message]
2025-09-18 17:02 ` Antonio Mennillo
2025-09-18 22:22 ` brian m. carlson
2025-09-19 21:14 ` Antonio Mennillo
2025-09-20 19:13 ` Elijah Newren
2025-09-21 14:06 ` Antonio Mennillo
2025-09-23 23:33 ` Antonio Mennillo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aMnhSm5QSdRwiJds@fruit.crustytoothpaste.net \
--to=sandals@crustytoothpaste$(echo .)net \
--cc=antoniomennillo87@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox