git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: Jacob Keller <jacob.keller@gmail.com>
Cc: Jacob Keller <jacob.e.keller@intel.com>,
	Git List <git@vger.kernel.org>, Johan Herland <johan@herland.net>,
	Michael Haggerty <mhagger@alum.mit.edu>
Subject: Re: [PATCH v2 2/2] notes: add notes.merge option to select default strategy
Date: Sun, 2 Aug 2015 04:01:23 -0400	[thread overview]
Message-ID: <20150802080123.GA17440@flurp.local> (raw)
In-Reply-To: <CA+P7+xpTu6eKZEBTbzR9mg4gV3zAvTOc-3PTJP6QamEO_sA1=A@mail.gmail.com>

On Sun, Aug 02, 2015 at 12:41:08AM -0700, Jacob Keller wrote:
> On Sat, Aug 1, 2015 at 7:46 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> >>  If conflicts arise and a strategy for automatically resolving
> >> -conflicting notes (see the -s/--strategy option) is not given,
> >> -the "manual" resolver is used. This resolver checks out the
> >> -conflicting notes in a special worktree (`.git/NOTES_MERGE_WORKTREE`),
> >> -and instructs the user to manually resolve the conflicts there.
> >> -When done, the user can either finalize the merge with
> >> -'git notes merge --commit', or abort the merge with
> >> -'git notes merge --abort'.
> >> +conflicting notes (see the -s/--strategy option or notes.merge
> >> +config option) is not given, the "manual" resolver is used.
> >> +This resolver checks out the conflicting notes in a special
> >> +worktree (`.git/NOTES_MERGE_WORKTREE`), and instructs the user
> >> +to manually resolve the conflicts there. When done, the user
> >> +can either finalize the merge with 'git notes merge --commit',
> >> +or abort the merge with 'git notes merge --abort'.
> >
> > When you re-wrap the text like this, it's difficult to spot your one
> > little change in all the diff noise. For the sake of review, it's
> > often better to minimize the change, even if it leaves the text more
> > jagged than you'd like.
> 
> This results in something incredibly jagged. I can't find a good way
> to split which minimizes the change. Would a 3rd patch which just
> re-flows this be an acceptable alternative
> 
> ie: add the words in one patch then re-flow afterwards in a second
> patch with no changes?
> 
> There is no good alternative as other re-flows I tried end up looking
> way too jagged, as compared to surrounding documentation.

Don't worry too much about it. Consider it something to keep in mind for
future patches. I reviewed the change and it seemed okay. I mentioned it
because one of the goals of patch submission, in addition to making an
actual change, is to ease the review process. If Junio is okay with
accepting it as is, then it's probably not worth spending more time
trying to refine it.

Having said that, I came up with the following for those two paragraphs,
which gives a much less noisy diff and doesn't look too jagged:

--- 8< ---
 If conflicts arise and a strategy for automatically resolving
-conflicting notes (see the -s/--strategy option) is not given,
-the "manual" resolver is used. This resolver checks out the
+conflicting notes (see -s/--strategy or notes.merge configuration) is
+not given, the "manual" resolver is used. This resolver checks out the
 conflicting notes in a special worktree (`.git/NOTES_MERGE_WORKTREE`),
 and instructs the user to manually resolve the conflicts there.
 When done, the user can either finalize the merge with
--- 8< ---

...and...

--- 8< ---
 	When merging notes, resolve notes conflicts using the given
-	strategy. The following strategies are recognized: "manual"
+	strategy. Overrides the "notes.merge" configuration variable.
+	The following strategies are recognized: "manual"
 	(default), "ours", "theirs", "union" and "cat_sort_uniq".
 	See the "NOTES MERGE STRATEGIES" section below for more
 	information on each notes merge strategy.
--- 8< ---

  reply	other threads:[~2015-08-02  8:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-31 23:12 [PATCH v2 0/2] notes: add notes.merge strategy option Jacob Keller
2015-07-31 23:12 ` [PATCH v2 1/2] notes: document cat_sort_uniq rewriteMode Jacob Keller
2015-07-31 23:12 ` [PATCH v2 2/2] notes: add notes.merge option to select default strategy Jacob Keller
2015-08-02  2:46   ` Eric Sunshine
2015-08-02  4:12     ` Jacob Keller
2015-08-02  7:41     ` Jacob Keller
2015-08-02  8:01       ` Eric Sunshine [this message]
2015-08-02  8:20         ` Jacob Keller
2015-08-01 13:30 ` [PATCH v2 0/2] notes: add notes.merge strategy option Johan Herland

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

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

  git send-email \
    --in-reply-to=20150802080123.GA17440@flurp.local \
    --to=sunshine@sunshineco.com \
    --cc=git@vger.kernel.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jacob.keller@gmail.com \
    --cc=johan@herland.net \
    --cc=mhagger@alum.mit.edu \
    /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.
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 NNTP newsgroup(s).