ENB: Changing branches safely

25 views
Skip to first unread message

Edward K. Ream

unread,
Apr 24, 2018, 4:32:34 PM4/24/18
to leo-editor
Recent work on paste-retaining-clones suggests straightforward principles needed to fix #863: Serious problems changing branches:

1. [New principle]: The only proper way to resolve clone conflicts is to give priority to clones within @<file> trees. Why did this principle never occur to me before?

2. [Old principle]: When resolving a clone conflict, it is useless to ask for the user's advice. No user, myself included, will have the faintest idea how to resolve a conflict. A dialog will simply cause panic.

3. [New principle]: When resolving a clone conflict, Leo must tell the user that a clone conflict occurred and what the resolution was. Leo's "Recovered nodes" might suffice in this regard. Or not.

4. [New principle]: When reading any @<file> node, (including refresh-from-disk), Leo must clear the entire @<file> tree. This is the only way to prevent unwanted nodes from appearing.

Principles 1 and 4 not only are compatible, they are complementary.  Ditto for principles 2 and 3.

Unless I am seriously mistaken these principles will lead to a straightforward solution for #863.

Edward

Edward K. Ream

unread,
Apr 24, 2018, 4:38:51 PM4/24/18
to leo-editor
On Tuesday, April 24, 2018 at 3:32:34 PM UTC-5, Edward K. Ream wrote:

> 1. [New principle]: The only proper way to resolve clone conflicts is to give priority to clones within @<file> trees. Why did this principle never occur to me before?

> 3. [New principle]: When resolving a clone conflict, Leo must tell the user...what the resolution was.

The worst, hardest case involves clone conflicts in two nodes, both of which are part of @<file> trees.  Perhaps in this case only the "last clone wins" rule can apply.  Happily, principle 3 will still apply.

There is an over-arching requirement: when switching git branches, we want to completely eliminate any surprises.  It would still be possible (though unlikely) for the clone resolution to change a outline such that rewriting the file would cause git to report a change. At present, such nasty surprises are all too common, and they happen without any warning at all.

Edward
Reply all
Reply to author
Forward
0 new messages