On Sat, Aug 1, 2015 at 7:46 PM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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. Regards, Jake -- 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