**Important**: keys branch merged into devel

48 views
Skip to first unread message

Edward K. Ream

unread,
Jul 25, 2020, 10:03:53 AM7/25/20
to leo-editor
This concludes #1269: refactor Leo's key-handling code.

Several weeks (months) ago I asked Leonistas to test the keys branch. I have received no complaints, but I'm not sure that means anything. Please report any problems.

The new code is much simpler than the old. We aren't going back. Any problems will be fixed in new branches.

Edward

Edward K. Ream

unread,
Jul 26, 2020, 6:52:07 AM7/26/20
to leo-editor
On Saturday, July 25, 2020 at 9:03:53 AM UTC-5, Edward K. Ream wrote:

> This concludes #1269: refactor Leo's key-handling code.

Rev 64c49da6 in devel restores an important key binding that was reverted when merging the "keys" branch into devel. The new binding is in leoSettings.leo, in the node @keys EKR bindings-->@shortcuts Text operations

old: newline-and-indent = !text = Tab
new: indent-region = !text = Tab

You will probably want to make a similar change in your myLeoSettings.leo file if you don't use the EKR bindings.

Edward

P. S. I am alarmed by the potential loss of data when merging git branches.

When I merged the "keys" branch into devel I mistakenly resolved a merge conflict by taking devel's version of leoSettings.leo. That was just wrong.

After deleting the "keys" branch, there seems to be no way recover the lost key bindings. I would have thought that the git merge would have preserved all previous changes to leoSettings.leo, but I was not able to see those changes. Fortunately, the required change could easily be deduced.

Hmm. Perhaps creating a PR, as I should have done, would have fixed the problem. Yes, I think so. The PR would have recorded the contents of leoSettings.leo, without knowing that a conflict would have resulted.

EKR

Thomas Passin

unread,
Jul 26, 2020, 7:44:37 AM7/26/20
to leo-editor
This teaches me not to rush to delete a branch once it's not needed any more.

Brian Theado

unread,
Jul 26, 2020, 11:32:29 AM7/26/20
to leo-editor
Edward,

On Sun, Jul 26, 2020 at 6:52 AM Edward K. Ream <edre...@gmail.com> wrote:
[...] 
P. S. I am alarmed by the potential loss of data when merging git branches.

When I merged the "keys" branch into devel I mistakenly resolved a merge conflict by taking devel's version of leoSettings.leo. That was just wrong.

After deleting the "keys" branch, there seems to be no way recover the lost key bindings. I would have thought that the git merge would have preserved all previous changes to leoSettings.leo, but I was not able to see those changes. Fortunately, the required change could easily be deduced.
[...]

From https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell, "a branch in Git is simply a lightweight movable pointer to one of these commits".  So when you delete a branch, you only lose the named pointer to the commit. Your merge commit shows which commit the keys branch used to point to:

$ git log -n1 818de411e61
commit 818de411e6130086714a2f6bcb97ab52e6182674
Merge: cc568d628 060811435
Author: Edward K. Ream <edre...@gmail.com>
Date:   Sat Jul 25 08:43:33 2020 -0500

    Merge devel into keys, using devel's leoSettings.leo

Before you deleted the keys branch, it pointed to commit cc568d628 and you can see the changes to leo settings with this command:

$ git log -p cc568d628 leo/config/leoSettings.leo

No commits are lost when you delete a branch.

A pull request from the keys branch into devel would have only helped you in that it would not have allowed you to merge into the devel branch due to the merge conflicts. You would have had to resolve the merge conflicts in the keys branch before merging into devel. There, one last round of testing might have exposed the issue, but maybe not. Or maybe inspecting the diffs one last time through the pull request UI might have helped you spot the issue. Either way, I don't think a PR provides any extra history preservation. The commits are all still there.

Brian

Edward K. Ream

unread,
Jul 26, 2020, 12:36:18 PM7/26/20
to leo-editor
On Sun, Jul 26, 2020 at 10:32 AM Brian Theado <brian....@gmail.com> wrote:

> From https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell, "a branch in Git is simply a lightweight movable pointer to one of these commits".  So when you delete a branch, you only lose the named pointer to the commit. Your merge commit shows which commit the keys branch used to point to:

Thanks for this. I'm less alarmed now :-)

However, I am not happy with gitk (or git log) as a means of seeing what has happened. Perhaps I am missing something. Yesterday I did discover git views, but they haven't helped nearly as much as I would have liked.

And where is the search function in gitk?

Edward

Brian Theado

unread,
Jul 26, 2020, 5:36:12 PM7/26/20
to leo-editor
The git log command I shared shows the diffs for leoSettings in your keys branch. That didn't help you?

$ git log -p cc568d628 leo/config/leoSettings.leo

Since all the history is still there, you could redo the merge locally using temporary throwaway branches. For educational purposes, if nothing else. But also you can use it to see what is different than if you had resolved the merge conflicts "correctly". What follows is my transcript of following that advice.

Create the throwaway, temporary branches

$ git branch old-keys cc568d628
$ git branch old-devel 060811435

Run the merge

$ git checkout old-devel
$ git merge old-keys
Auto-merging leo/core/leoGlobals.py
Auto-merging leo/core/leoCommands.py
Auto-merging leo/config/leoSettings.leo
CONFLICT (content): Merge conflict in leo/config/leoSettings.leo
Auto-merging leo/commands/editCommands.py
Automatic merge failed; fix conflicts and then commit the result.

The conflict looks pretty easy to resolve. New vnodes were added in the same place in both branches. All the new vnodes should be kept

$ git diff leo/config/leoSettings.leo
diff --cc leo/config/leoSettings.leo
index 7c2977cb8,bab3e06d2..000000000
--- a/leo/config/leoSettings.leo
+++ b/leo/config/leoSettings.leo
@@@ -2321,7 -2319,8 +2321,12 @@@
  <v t="tbrown.20140505094209.37266"><vh>@bool outline-tabs-show-close = True</vh></v>
  </v>
  </v>
++<<<<<<< HEAD
 +<v t="ekr.20110611092035.16480"></v>
++=======
+ <v t="ekr.20060603215208"></v>
+ <v t="ekr.20060925060533.4"></v>
++>>>>>>> old-keys
  </vnodes>
  <tnodes>
  <t tx="TL.20080702085131.2">If True: Save the Leo file and all modified derived files every time the external editor saves a modified file.

Since we want to keep all the lines, use vim to remove the "<<<<<", "=====", ">>>>>>" merge conflict cruft:

$ vim leo/config/leoSettings.leo

Commit the merge

$ git add leo/config/leoSettings.leo
$ git commit -m "Merged old-keys into old-devel"

See what changes from the keys branch still aren't in devel. Looks like there are a few still:

$ git diff devel..old-devel leo/config/leoSettings.leo
diff --git a/leo/config/leoSettings.leo b/leo/config/leoSettings.leo
index 7c01ef527..dac0e2cbf 100644
--- a/leo/config/leoSettings.leo
+++ b/leo/config/leoSettings.leo
@@ -2321,7 +2321,9 @@
 <v t="tbrown.20140505094209.37266"><vh>@bool outline-tabs-show-close = True</vh></v>
 </v>
 </v>
+<v t="ekr.20110611092035.16480"></v>
 <v t="ekr.20060603215208"></v>
+<v t="ekr.20060925060533.4"></v>
 </vnodes>
 <tnodes>
 <t tx="TL.20080702085131.2">If True: Save the Leo file and all modified derived files every time the external editor saves a modified file.
@@ -3612,19 +3614,25 @@ delete-comments                     = Ctrl-parenright # Shift-Ctrl-0
 delete-word                         = Ctrl-Delete
 delete-word                         = Keypad+Ctrl+Delete
 delete-spaces                       = None
+### NEW:
 indent-region                       !text = Tab
-indent-region                       = ctrl-greater # Ctrl-shift-&gt;
+### OLD:
+# indent-region                     = Tab # Only when text is selected.
+# indent-region                     = ctrl-greater # Ctrl-shift-&gt;
 kill-line                           = Ctrl-k
 kill-to-end-of-line                 = None
-newline-and-indent                  = Ctrl-j
-### newline-and-indent              !text = Tab
+# newline-and-indent                = Ctrl-j
+# newline-and-indent                !text = Tab
 focus-to-body                       !tree = Tab
 paste-text                          = Ctrl-v
 reformat-paragraph                  = Shift-Ctrl-p
 split-line                          = None
 unformat-paragraph                  = Shift-Ctrl-u
-unindent-region                     = ctrl-less # Ctrl-Shift-&lt;
-unindent-region                     = Shift-tab # Only when text is selected.
+### NEW
+unindent-region                     !text = Shift-Tab
+# OLD:
+# unindent-region                     = ctrl-less # Ctrl-Shift-&lt;
+# unindent-region                     = Shift-tab # Only when text is selected.
 yank                                = Ctrl-Y
 yank-pop                            = Alt-Y
 zap-to-character                    = Alt-z</t>

Brian

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS2x99q53QW%2BnGeSHRe9%2Bue9Fj02mNuY5kvJ9m3oH95zDA%40mail.gmail.com.

Edward K. Ream

unread,
Jul 27, 2020, 7:20:31 AM7/27/20
to leo-editor
On Sun, Jul 26, 2020 at 4:36 PM Brian Theado <brian....@gmail.com> wrote:
The git log command I shared shows the diffs for leoSettings in your keys branch. That didn't help you?

$ git log -p cc568d628 leo/config/leoSettings.leo

Wow. Great job of sleuthing. Finding this commit was what stumped me.

I just learned something new about gitk. If I enter "cc568d628" into the SHA1 ID box, the title changes to "Goto". Clicking "Goto" takes me to the commit.

This also partially answers the question of how you found it. The checkin log is "Merge branch 'devel' into keys".

And now ` git log -p cc568d628 leo/config/leoSettings.leo` shows what the conflict was.

And thanks for the rest of your post. I'll study it.

Edward
Reply all
Reply to author
Forward
0 new messages