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. > gpyfm considers everything a diff. So if you accept a change it adds a diff to the undo stack. If you type in the merge window it creates a diff and adds that to the undo stack. (It tries to combine typing changes though so you don't undo one freaking letter at a time). If you "auto-merge" it puts all of the diffs it could merge on the undo stack. (So undo after auto-merge undoes all automatic merges).
Filemerge only had undo for merges, not anything you type in the merge window. To undo selected would require a lot of effort. To undo all (basically go back to the beginning) shouldn't be that hard. You just keep applying undo until the stack is empty. > >>> 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. > That was a "feature" of Filemerge I really never liked, adding blank lines in the merge. In gpyfm you accept either the parent/child or reject both parent and child. And then you type anything else you might want. So reject is really your "Mark Resolved". One click of auto-merge will get you to where Filemerge initialized things. I'm not a big fan of automerge as you can miss important changes that require you to type in the merge window. I do think Mark Nelson's suggestion of adding greyed out lines in parent/child to line up that text is a good idea, but that's a different issue. > Mike> I think we'll eventually want "Save As". Some of our source files > Mike> are large enough that I don't trust copy/paste to work flawlessly. > Mike> Of course, this isn't a navigation option, so feel free to ignore > Mike> "Save As" for now. > > Rich> Why would you be copy/pasting? > > For the cases where I want to save my work, but I don't want to follow > through on the merge for some reason. I haven't done this much with > FileMerge, probably a handful of times (over 14+ years), so it's > not high priority. > > Mike> I don't know what "Selected Difference" does, so I expect we can > Mike> ignore it. > > Rich> I would imagine it'd scroll the view to the currently selected > Rich> chunk (as a quick-way to re-find the current point after free > Rich> scrolling). Even if it's not, that's a feature I'd like. > > Yeah, I can see where it would be useful. > > mike > > > >
