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