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

[Junio C Hamano <gitster@pobox.com>]

Michael Montalbo <mmontalbo@gmail.com> writes:

> 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

Sure, but I do not think of a reason why the posted patches cannot
later be extended in that direction if somebody wanted to (but
because the option is called "--resolved", the command line would
need to become "add --resolved --allow-conflict-markers").  I just
did not feel the need for it myself, and because --allow would be a
rare case, I would likely do "git add --resolved", see it fail due
to conflict marker looking strings that are deliberately left in,
and then do "git add $path" to cover these small exceptions, i.e., I
do not think anybody would need "--allow-conflict-markers" option.

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

Have no idea how the user recovers after performing an operation
like that.

The naming is very much deliberate.  "git am --resolved" tells the
command "I am done with them, so please continue".  It is not like I
want to add anything that are unmerged.  I dealt with unmerged stuff
and turned them into the resolved state, and the command is a request
to record that fact.  It is a regression to call it "--unmerged".