Mike Kupfer wrote: >>>>>> "Rich" == Richard Lowe <richlowe at richlowe.net> writes: > >>> Undo> >>> Last Resolved >>> Selected >>> All > > Rich> I very much want these distinctions, and looked into > Rich> implementation, it *looked* like these would be complicated by > Rich> hand-edits of the merge buffer. > > Could be (I haven't looked at gpyfm's internals). I don't know what > FileMerge does in the face of hand-edits. > >>> Mark Selected as Resolved >>> Mark Remaining as Resolved > > Rich> Is this effectively an "accept ancestor"? > > No. Filemerge initializes the result buffer to the non-conflicting > lines, plus anything it can auto-resolve. For the conflicts it can't > resolve, it puts in one or more blank lines. Marking as Resolved leaves > the blank lines there. >
I wonder why gpyfm doesn't default to the auto-merge behaviour (gpyfm's auto-merge accepts only non-conflicting changes.) Is there rationale there? I can appreciate it forces people to pay attention, but the cynic in me suggests "They'll just hit automerge anyway" and the optimist says "They should be paying attention *anyway*" -- Rich
