Phil Hord <phil.hord@xxxxxxxxx> writes:
>>> .... 'mergetool' uses this command to
>>> avoid asking the user to resolve files which git rerere already
>>> resolved for her.
>>
>> Ok, so "Print paths with conflicts that are not resolved." indeed is
>> sufficient.
>
> If you goal is to say as little as possible, then yes. But I had to
> read the related commit messages several times before it dawned on me
> what the distinction was.
The goal is "Concise, coherent and clear"; "as little as possible"
never is. We need to elaborate as needed but make sure we do not
tire readers with irrelevant explanation.
The first problem I had with the patch (go back and re-read the
patch and its initial review) was "Like 'diff', but...". It is not
"Like diff" at all (if anything, it is more like "status", but
"status" in turn is not "Like diff" either). We can first drop that
part and spend more words to describe what it really is.
> The main problem was that I didn't
> understand that I was missing 'rerere.autoupdate=true' in my config,
> or why it mattered. I only know that rerere was letting me down
> sometimes, and 'rerere remaining' seemed to be missing some
> clearly-still-unresolved files.
Personally, I think you are being *good* by not using autoupdate.
Once you let rerere auto-update, it will become hard to notice a
mismerge when previous resolution is applied when it shouldn't, and
even harder to correct it ("checkout -m" will not work).
> Thanks to this proposal, I understand it better now. But not from
> reading this email thread.
Care to give a crack at it, then?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html