Re: [PATCH] Documentation/git-rerere: document 'remaining' command

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 8, 2012, 05:23 UTC
Message-ID: <7vr4x3is39.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CABURp0run5zYLBkUsNQEJq3h_1y7bQ44XZb9BPja+RjX8OLyfg@mail.gmail.com>

Phil Hord <phil.hord@gmail.com> writes:

Show 10 quoted lines

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

Show 5 quoted lines

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