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

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

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

> On Thu, Mar 8, 2012 at 12:23 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Phil Hord <phil.hord@gmail.com> writes:
> ...
>   $ git rebase origin/master
>    Noise, noise, noise
>    Resolved 'foo' using previous resolution.
>    Failed to merge in the changes.
>
> I reach for my utility belt, but my usual tricks all fail at this point:
>
>    $ git mergetool
>    No files need merging
>
>    $ git rebase --continue
>    foo: needs merge

Just to make sure we are on the same page (I do not personally use
"mergetool"), the above looks like a bug in mergetool.

Are you reporting a still-unfixed breakage, or is it an anecdote on
how you were frustrated in the past due to a bug that has since been
fixed?

> How's this:

Looks good.

>  'status'::
>
> -Like 'diff', but this only prints the filenames that will be tracked
> -for resolutions.
> +Print paths with conflicts whose merge resolution rerere will record.
> +
> +'remaining'::
> +
> +Print paths with conflicts that have not been autoresolved by rerere.
> +This includes paths whose resolutions cannot be tracked by rerere,
> +such as conflicting submodules.

We might want to add "and a path that was deleted by one branch and
modified by the other branch" at the end here.

Unless an earlier part of the documentation that discusses what kind
of resolutions get recorded and reapplied makes it clear enough that
the reader can easily guess a delete/modify conflict is not handled,
that is.  I _think_ the description at the top makes it clear the
two branches being merged both need to have a file at the path, so
in that sense, singling out delete/modify and mentioning it here
might be redundant, but I am not the target audience (I wrote and
named it rerere after all ;-), so I shouldn't be my own judge.

Thanks.