Re: [PATCH v3 0/4] git add --resolved
Jeff King <[email protected]> Sat, 1 Aug 2026 10:14:14 -0400
| Newsgroups | org.kernel.vger.git |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Jul 31, 2026 at 05:56:01AM -0700, Junio C Hamano wrote:
> When you are the maintainer of a project and make many merges day
> in, day out, a lot of your time is spent resolving conflicts and
> adding the results to the index. It is not unusual to have local
> changes in your working tree that are unrelated to any particular
> merge [*]. In such cases, 'git add -u', which adds all changes in
> the working tree to the index, does not help much.
>
> Here is a new option for 'git add' that lets you add paths with
> resolved conflicts to the index, while keeping unrelated local
> changes out.
I think this is a reasonable thing to want, but just playing devil's
advocate for a moment: how big of a footgun might this be?
We have some changes in the working tree, we try a merge and get
conflicts, do some resolving work and now we want to stage the
resolution but nothing else. How close is --resolved to that? I can
think of two corner cases:
1. There are non-merge changes in foo.c, which also had some
conflicts. Because we stage the whole file, we accidentally stage
those along with the merge resolution.
But maybe this is impossible, because merge would have refused to
operate when one of the changed files is dirty? I think this is
dependent on the strategy, but it should be true for most
strategies. The exception is "ours", but that does not create
conflicts in the first place. ;)
2. Your resolution required touching other files (e.g., updating the
caller of a function), but we'll ignore them. Git has no idea that
those changes are related to the merge and not just stray changes.
You have to remember to stage them manually.
This is a problem even without --resolved, but I think it's easy
for --resolved to lure you into a false sense of security that it
is staging all of the important bits.
That doesn't seem too bad to me. I was mostly worried about (1), but
after digging into it, I think I've convinced myself that it's a
non-issue.
-Peff