Re: [PATCH v2 0/4] git add --resolved

On Wed, Jul 29, 2026 at 11:37 AM Junio C Hamano <[email protected]> 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.

Please take this feedback with a grain of salt, as I am probably not
the target audience for this feature and am still familiarizing myself
with the concepts involved.

I wonder if it would make sense to separate the structural selection
of unmerged paths from the conflict-marker safety policy.

For example, could the user-facing option be something like:

    git add --unmerged

with the same default behavior being proposed: select only unmerged
index entries, and refuse the operation if any selected regular file
contains standard Git conflict markers.

That would also potentially leave room for explicit policy escape
hatches later, such as:

    git add --unmerged --allow-conflict-markers

for cases where marker-looking content is intentional; or
something like:

    git add --unmerged --skip-conflict-markers

for a mode that stages marker-free unmerged paths while leaving
marker-containing paths unmerged and returning non-zero.

I do see the argument for "--resolved" in terms of naming the option
after the workflow the user is performing when resolving conflicts. My
main feedback is that the implementation selects unmerged paths and
applies a conflict-marker safety check, rather than determining semantic
resolution, which a name like "--resolved" might imply more strongly.