Conflict resolution and buffer saving

[smashwilson]

When you resolve conflicts in an open file with the resolution controls, the resolution happens within the unsaved buffer, but the "remaining conflicts" count in the Git panel is decreased immediately. If you close the open editor without saving, the "remaining conflicts" count will revert, but if you stage the conflicted file (even if it says "ready") the last saved version of the buffer is what's actually being staged. This is confusing.

A few possible approaches to making this smoother:

(i) Save automatically after clicking a resolution control

As suggested by @nathansobo

The only problem I see with this one is that it's sometimes useful to keep an editor unsaved when doing a bunch of risky edits; it leaves you the escape hatch of closing-without-saving, then reopening and starting over. Of course, this is git, so you can get that state back using git commands, or abort and re-try the entire merge.

(ii) Save the unsaved buffer automatically when staging

When beginning to stage any conflicted file, first attempt to save any TextEditors that have the file open and have unsaved changes. This one gets ugly if you have the buffer open in several panes at once, with different unsaved changes in each. I'm not sure how to handle that.

(iii) Only update the "conflicts remaining" count on save

This removes the ambiguity, but at the cost of deferring that nice, satisfying decreasing count. I like the immediately feedback it gives you about the progress you're making through the file.

(iv) Show additional state in the "conflicts remaining" area

Differentiate between persisted and unpersisted resolutions in the conflict countdown, and only show the green check once all of the resolutions are persisted. I think it'd take some careful verbiage not to make this really befuddling or use too much screen real estate.

/cc @nathansobo @BinaryMuse @simurai

[smashwilson]

Thinking about (iv), maybe we could have an "unsaved data" dot next to the file in the "conflicted files" list if a TextEditor has it open with unsaved changes? The green check for "ready" wouldn't appear until it was gone. That might be enough of a trigger to remind you that you need to save without having to add a bunch of other info there.

[simurai]

✋ vote for iii. Because clicking on one of the resolution controls might not necessarily mean that your are done resolving. You might still want to edit it by hand. Just once you saved you're saying "I'm done! Show the checkmark".

Or iV with the "unsaved dot" might be ok too. If the meaning feels clear enough.

[nathansobo]

Sorry for the late reply... I think I like iv. Maybe surfacing the fact that files have unsaved state in the commit panel generally could avoid confusion without taking unwanted action on the user's behalf.

[freeatnet]

Does this issue need help?