git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Phil Hord <phil.hord@gmail.com>
Cc: Vincent van Ravesteijn <vfr@lyx.org>,
	git@vger.kernel.org, martin.von.zweigbergk@gmail.com
Subject: Re: [PATCH] Documentation/git-rerere: document 'remaining' command
Date: Wed, 07 Mar 2012 21:23:22 -0800	[thread overview]
Message-ID: <7vr4x3is39.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CABURp0run5zYLBkUsNQEJq3h_1y7bQ44XZb9BPja+RjX8OLyfg@mail.gmail.com> (Phil Hord's message of "Wed, 7 Mar 2012 22:08:16 -0500")

Phil Hord <phil.hord@gmail.com> 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?

  reply	other threads:[~2012-03-08  5:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-06 12:21 [PATCH] Documentation/git-rerere: document 'remaining' command Vincent van Ravesteijn
2012-03-06 19:24 ` Junio C Hamano
2012-03-07 22:10   ` Phil Hord
2012-03-07 22:24     ` Junio C Hamano
2012-03-08  3:08       ` Phil Hord
2012-03-08  5:23         ` Junio C Hamano [this message]
2012-03-08 21:08           ` Phil Hord
2012-03-08 22:30             ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vr4x3is39.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=martin.von.zweigbergk@gmail.com \
    --cc=phil.hord@gmail.com \
    --cc=vfr@lyx.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).