Re: A road to branch pollution: git stash goes back in time

[Edward K. Ream]

On Sun, Jul 16, 2017 at 11:15 PM, Xavier G. Domingo 
wrote:

>
> Anyway, for those of you that need to *continuously work with various git
> branches in parallel*, I've recently come across a better way of doing
> it: Git Worktrees .
>

​Thanks for this.  I'll keep it in mind.

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Edward K. Ream]

On Sun, Jul 16, 2017 at 3:52 PM, vitalije  wrote:

> The recovered nodes are *not* a sign of problems (any more).  They could
>> be called a courtesy--a note that code is different in the new branch from
>> the previous branch.
>>
>> The acid test is to save all files (write-at-file-nodes) after switching
>> branches.  Any changed file is a serious error.
>>
>
> Yes, I see it now. Recovered nodes still appear from time to time, but no
> changed files after write-at-file-nodes. So, everything is in order :-)
>

​Excellent​. Thanks for the confirmation.

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Xavier G. Domingo]

El 16/07/2017 a las 15:52, Edward K. Ream escribió:


On Sun, Jul 16, 2017 at 12:29 PM, vitalije > wrote:



Having said that, my earlier recommendation than one should avoid
switching branches in same folder is not valid any more.


​That's great news.​



Glad to know this! It's an important step forward.

Anyway, for those of you that need to *continuously work with various 
git branches in parallel*, I've recently come across a better way of 
doing it: Git Worktrees 
. It was introduced 
in Git 2.5 and allows you to have various branches of the same 
repository simultaneously checked out in separate folders, so you don't 
have to do the typical stash-checkout-... workflow when you need to 
switch branches with still WIP in the current one...


If you are going to use it, my advice would be to add worktree's folders 
*as siblings* of the current working folder.


I mean, doing something like this:

cd leo-editor
git checkout master
git worktree add *../second_branch *second_branch

Here is an example using current Leo branches:

   C:\dev\leo-master>*git checkout master*

   C:\dev\leo-master>*git worktree add ..\leo-sqlite-leo sqlite-leo*
   Preparing ../leo-sqlite-leo (identifier leo-sqlite-leo)
   Checking out files: 100% (4873/4873), done.
   HEAD is now at 44871a551 Merge branch 'master' of
   github.com:leo-editor/leo-editor into sqlite-leo

   C:\dev\leo-master>*cd ..\leo-sqlite-leo*

   C:\dev\leo-sqlite-leo>*git status*
   *On branch sqlite-leo*
   Your branch is behind 'origin/sqlite-leo' by 127 commits, and can be
   fast-forwarded.
  (use "git pull" to update your local branch)
   nothing to commit, working tree clean

   C:\dev\leo-sqlite-leo>*git pull*
   ...

Xavier

--
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[vitalije]

>
> The recovered nodes are *not* a sign of problems (any more).  They could 
> be called a courtesy--a note that code is different in the new branch from 
> the previous branch.
>
> The acid test is to save all files (write-at-file-nodes) after switching 
> branches.  Any changed file is a serious error.
>

Yes, I see it now. Recovered nodes still appear from time to time, but no 
changed files after write-at-file-nodes. So, everything is in order :-)

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Terry Brown]

On Sun, 16 Jul 2017 13:47:40 -0500
"Edward K. Ream"  wrote:

> On Sun, Jul 16, 2017 at 10:49 AM, Terry Brown 
> wrote:
> 
> As long as Leo's refresh from disk code works reasonably and as long
> as you **always say yes to all** when Leo prompts for reload on
> external changes, it doesn't seem like there should be a problem.
> 
> ​I agree. This is the missing "ingredient".  Or just close Leo when
> switching branches, but that should not be necessary.

If in doubt, I'll sometimes open myLeoSettings.leo, close the outline
with my work in it, then re-open it.  Faster than exiting Leo
completely - myLeoSettings.leo is irrelevant, it just serves to keep
Leo open, any other outline would do.

Shouldn't be necessary, but handy when you want to be sure - or if
you've ignored / lost track of "yes to all" prompts.

Cheers -Terry

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Edward K. Ream]

On Sun, Jul 16, 2017 at 1:18 PM, Terry Brown  wrote:

> While I will leave it to Edward to agree or disagree, I'd just point out
> that the c.db and g.db API must remain unchanged for all the non - cache
> uses they have, including in personal code we can't mass edit.
>

​I had forgotten about that.  Glad you mentioned it.

Edward​

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Edward K. Ream]

On Sun, Jul 16, 2017 at 12:29 PM, vitalije  wrote:
>
>
> Having said that, my earlier recommendation than one should avoid
> switching branches in same folder is not valid any more.
>

​That's great news.​


I still don't know if leoCache was responsible for all those problems, or
> perhaps new-read solved some problems elsewhere that Edward had noticed,
> and problems that I have noticed were caused only by sqlite-leo bug.
>

​For sure there are serious problems without the new-read code.​


We shall see. If creating recovered nodes when switching branches is still
> happening in master branch, then most probably problems come from cache.
>
​
The recovered nodes are *not* a sign of problems (any more).  They could be
called a courtesy--a note that code is different in the new branch from the
previous branch.

The acid test is to save all files (write-at-file-nodes) after switching
branches.  Any changed file is a serious error.

​

> One way or the other, sqlite-leo doesn't use leoCacher anymore to look for
> files and as a result all problems with switching branches disappeared.
>

​Cool!
​


> In the past, leoCache.py was a great addition, but I'm starting to think
>> it may be nearing the end of it's useful life.  I am willing to consider
>> replacing it with sqlite code.
>>
>
> If you agree I can write new version of Cacher that uses sqlite db as
> backend and stores all cache values in one file. This can be convenient
> especially for debugging purposes.
>

​Please give it a go.  I would like to experiment with it.
​


> If ever cache is suspected to be source of problem, it would be easy to
> rename database file or just table inside database which would have same
> effect as deleting cache folder. However, it gives much more flexibility in
> querying which cache record is actually problematic and extracting it for
> further investigation or use in unit tests.
>

​Thanks for all this. These are exciting times.

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Edward K. Ream]

On Sun, Jul 16, 2017 at 10:49 AM, Terry Brown  wrote:

>
> As long as Leo's refresh from disk code works reasonably and as long as
> you **always say yes to all** when Leo prompts for reload on external
> changes, it doesn't seem like there should be a problem.
>

​I agree. This is the missing "ingredient".  Or just close Leo when
switching branches, but that should not be necessary.

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[vitalije]

On Sunday, July 16, 2017 at 8:21:40 PM UTC+2, Terry Brown wrote:
>
> P.S meant to say that apart from preserving the API I see no issues with 
> switching the cache backend, unless some one was using pickleshare directly 
> to access it outside Leo, seems unlikely. 
>
> Yes, that is what I assumed also. In fact, I have introduced one global 
switch in leoCacher.py and according to that switch Cacher object will 
create either PickleShareDB (as it is doing now) or SqlitePickleShare which 
I am currently writing. SqlitePickleShare should be complete replacement 
for PickleShareDB with same public API. So even if someone was using 
directly PickleShareDB, should not be able to notice any difference. The 
only noticeable difference will be in file system. SqlitePickleShare will 
use one file while PickleShareDB was creating and deleting many files in 
one folder.

Vitalije

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Terry Brown]

P.S meant to say that apart from preserving the API I see no issues with 
switching the cache backend, unless some one was using pickleshare directly to 
access it outside Leo, seems unlikely. 


On July 16, 2017 12:29:56 PM CDT, vitalije  wrote:
>What I found is that there was a bug in sqlite-leo code which prevented
>
>refresh-from-disk to work quite reliably. Happily, I have found and
>fixed 
>it. In sqlite-leo branch as from cbb8f876854b looking for a file in Leo
>
>cache is fully avoided. That brought small speed up in starting Leo.
>Master 
>version of Leo opens LeoPyRef.leo with 100% cache hit on my machine in 
>1.27s and sqlite-leo opens same file but in db version, in 1.03s. This 
>speed gain is not a big deal, but now I can switch branches however I
>want 
>and Leo responds correctly. No recovered/resurrected nodes, ... both
>while 
>Leo is running and when it is first closed, branch switched and then
>opened 
>again. 
>
>Having said that, my earlier recommendation than one should avoid
>switching 
>branches in same folder is not valid any more.
>
>I still don't know if leoCache was responsible for all those problems,
>or 
>perhaps new-read solved some problems elsewhere that Edward had
>noticed, 
>and problems that I have noticed were caused only by sqlite-leo bug.
>
>We shall see. If creating recovered nodes when switching branches is
>still 
>happening in master branch, then most probably problems come from
>cache. If 
>they don't appear anymore then most probably those problems were solved
>in 
>new-read branch and now fix is merged in master. 
>
>One way or the other, sqlite-leo doesn't use leoCacher anymore to look
>for 
>files and as a result all problems with switching branches disappeared.
>
>
>In the past, leoCache.py was a great addition, but I'm starting to
>think 
>> it may be nearing the end of it's useful life.  I am willing to
>consider 
>> replacing it with sqlite code.
>>
> 
>If you agree I can write new version of Cacher that uses sqlite db as 
>backend and stores all cache values in one file. This can be convenient
>
>especially for debugging purposes. If ever cache is suspected to be
>source 
>of problem, it would be easy to rename database file or just table
>inside 
>database which would have same effect as deleting cache folder.
>However, it 
>gives much more flexibility in querying which cache record is actually 
>problematic and extracting it for further investigation or use in unit 
>tests. 
>
>Vitalije
>
>-- 
>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+unsubscr...@googlegroups.com.
>To post to this group, send email to leo-editor@googlegroups.com.
>Visit this group at https://groups.google.com/group/leo-editor.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Terry Brown]

While I will leave it to Edward to agree or disagree, I'd just point out that 
the c.db and g.db API must remain unchanged for all the non - cache uses they 
have, including in personal code we can't mass edit. 

Cheers - Terry 

On July 16, 2017 12:29:56 PM CDT, vitalije  wrote:
>What I found is that there was a bug in sqlite-leo code which prevented
>
>refresh-from-disk to work quite reliably. Happily, I have found and
>fixed 
>it. In sqlite-leo branch as from cbb8f876854b looking for a file in Leo
>
>cache is fully avoided. That brought small speed up in starting Leo.
>Master 
>version of Leo opens LeoPyRef.leo with 100% cache hit on my machine in 
>1.27s and sqlite-leo opens same file but in db version, in 1.03s. This 
>speed gain is not a big deal, but now I can switch branches however I
>want 
>and Leo responds correctly. No recovered/resurrected nodes, ... both
>while 
>Leo is running and when it is first closed, branch switched and then
>opened 
>again. 
>
>Having said that, my earlier recommendation than one should avoid
>switching 
>branches in same folder is not valid any more.
>
>I still don't know if leoCache was responsible for all those problems,
>or 
>perhaps new-read solved some problems elsewhere that Edward had
>noticed, 
>and problems that I have noticed were caused only by sqlite-leo bug.
>
>We shall see. If creating recovered nodes when switching branches is
>still 
>happening in master branch, then most probably problems come from
>cache. If 
>they don't appear anymore then most probably those problems were solved
>in 
>new-read branch and now fix is merged in master. 
>
>One way or the other, sqlite-leo doesn't use leoCacher anymore to look
>for 
>files and as a result all problems with switching branches disappeared.
>
>
>In the past, leoCache.py was a great addition, but I'm starting to
>think 
>> it may be nearing the end of it's useful life.  I am willing to
>consider 
>> replacing it with sqlite code.
>>
> 
>If you agree I can write new version of Cacher that uses sqlite db as 
>backend and stores all cache values in one file. This can be convenient
>
>especially for debugging purposes. If ever cache is suspected to be
>source 
>of problem, it would be easy to rename database file or just table
>inside 
>database which would have same effect as deleting cache folder.
>However, it 
>gives much more flexibility in querying which cache record is actually 
>problematic and extracting it for further investigation or use in unit 
>tests. 
>
>Vitalije
>
>-- 
>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+unsubscr...@googlegroups.com.
>To post to this group, send email to leo-editor@googlegroups.com.
>Visit this group at https://groups.google.com/group/leo-editor.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[vitalije]

What I found is that there was a bug in sqlite-leo code which prevented 
refresh-from-disk to work quite reliably. Happily, I have found and fixed 
it. In sqlite-leo branch as from cbb8f876854b looking for a file in Leo 
cache is fully avoided. That brought small speed up in starting Leo. Master 
version of Leo opens LeoPyRef.leo with 100% cache hit on my machine in 
1.27s and sqlite-leo opens same file but in db version, in 1.03s. This 
speed gain is not a big deal, but now I can switch branches however I want 
and Leo responds correctly. No recovered/resurrected nodes, ... both while 
Leo is running and when it is first closed, branch switched and then opened 
again. 

Having said that, my earlier recommendation than one should avoid switching 
branches in same folder is not valid any more.

I still don't know if leoCache was responsible for all those problems, or 
perhaps new-read solved some problems elsewhere that Edward had noticed, 
and problems that I have noticed were caused only by sqlite-leo bug.

We shall see. If creating recovered nodes when switching branches is still 
happening in master branch, then most probably problems come from cache. If 
they don't appear anymore then most probably those problems were solved in 
new-read branch and now fix is merged in master. 

One way or the other, sqlite-leo doesn't use leoCacher anymore to look for 
files and as a result all problems with switching branches disappeared. 

 In the past, leoCache.py was a great addition, but I'm starting to think 
> it may be nearing the end of it's useful life.  I am willing to consider 
> replacing it with sqlite code.
>
 
If you agree I can write new version of Cacher that uses sqlite db as 
backend and stores all cache values in one file. This can be convenient 
especially for debugging purposes. If ever cache is suspected to be source 
of problem, it would be easy to rename database file or just table inside 
database which would have same effect as deleting cache folder. However, it 
gives much more flexibility in querying which cache record is actually 
problematic and extracting it for further investigation or use in unit 
tests. 

Vitalije

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Terry Brown]

On Sun, 16 Jul 2017 06:21:05 -0700 (PDT)
vitalije  wrote:

> As I wrote in this comment 
> , 
> I had a serious trouble with this branch pollution thing. 
> My advice is never to develop two separate branches in the same
> folder. Every branch deserves its own folder. At least this is true
> when using Leo with cache enabled, especially if using sqlite-leo
> version of Leo.
> 
> I plan to investigate this thoroughly and until (if ever) I really 
> understand what and how can possibly go wrong, I would keep all
> branches in dedicated folders.
> Vitalije

This may be the safest policy, but I've never had trouble in my
probably more limited branch switching in Leo (with caching).

As long as Leo's refresh from disk code works reasonably and as long as
you **always say yes to all** when Leo prompts for reload on external
changes, it doesn't seem like there should be a problem.

As soon as you skip saying "yes to all", there's a possibility that
Leo's loaded copy is from a different branch, and anything that occurs
to cause it to be saved causes cross branch copying, in effect.

I've probably done much less branch switching than you two, Edward and
Vitalije, but apart from the quite reasonable (although very
detrimental) cross branch contamination arising from the above lack of
yes to all, it seems there shouldn't be a problem unless reloading or
caching isn't working correctly.

There might be some related issues like what to do if you don't reload
a file when Leo asks, then cause it to be written later - should Leo
remind you again it doesn't match the disk copy?  Probably best if it
did.  Particularly seeing Leo's realtime checking for external changes
can be switched off for slow filesystems etc.

Cheers -Terry

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Edward K. Ream]

On Sun, Jul 16, 2017 at 8:21 AM, vitalije  wrote:

> As I wrote in this comment
> ,
> I had a serious trouble with this branch pollution thing.
>

​This is troubling.  I have not had any real problems since merging the
new-read branch into all my branches.

The master branch now contains the new-read code, so I would not expect​
problems if you clear all your caches one last time and merge master into
all your branches. By clearing all caches I mean deleting all folders
inside ~/.leo/db.

But you have likely done all this.

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Edward K. Ream]

On Sun, Jul 16, 2017 at 8:21 AM, vitalije  wrote:

​> ​
As I wrote in this comment
,
I had a serious trouble with this branch pollution thing.
​
Many thanks for this detailed comment.  In the past, leoCache.py was a
great addition, but I'm starting to think it may be nearing the end of it's
useful life.  I am willing to consider replacing it with sqlite code.
​

​> ​
My advice is never to develop two separate branches in the same folder.

​An interesting idea.  How do you do that?

> I plan to investigate this thoroughly and until (if ever) I really
understand what and how can possibly go wrong, I would keep all branches in
dedicated folders.

That would be excellent.  I admire your willingness to tackle the most
difficult parts of Leo.

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[vitalije]

As I wrote in this comment 
, 
I had a serious trouble with this branch pollution thing. 
My advice is never to develop two separate branches in the same folder. 
Every branch deserves its own folder. At least this is true when using Leo 
with cache enabled, especially if using sqlite-leo version of Leo.

I plan to investigate this thoroughly and until (if ever) I really 
understand what and how can possibly go wrong, I would keep all branches in 
dedicated folders.
Vitalije

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Edward K. Ream]

On Monday, July 10, 2017 at 10:05:54 AM UTC-5, Edward K. Ream wrote:

If I have written a file in master, I have also written it to *master's* 
> cache.  Doing git branch -b doesn't clear that cache.
>
> As a result, on several occasions I have gotten this:
> Internal Leo error in checkForChangedNodes
>

New code in master simply omits this warning.

Experiments show that this policy is reasonable.  Indeed, Leo will create 
recovered nodes for "unexpected" changes that arise when switching 
branches.  These alert the user of *potential* problems.  Leo will alert 
the user of *actual* problems when writing changed files.  And if that 
isn't enough, the user can always restore code using git's recovery 
mechanisms.

In short, the only real problem with the previous read logic was a 
way-too-alarming internal error message.

I have once again closed #505: Leo's read code must be rewritten. 


The new-read branch is now dormant. Btw, my new policy is to retain dormant 
branches indefinitely on GitHub.

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Edward K. Ream]

On Friday, July 14, 2017 at 10:50:22 AM UTC-5, Edward K. Ream wrote:

refresh-from-disk should work *exactly* like the read code, but apparently 
> not.
>
> There is likely some subtle problem with Leo's read code.  As usual, 
> clones are a prime suspect.
>

I have just reopened #505: Leo's read code must be rewritten 
 to handle this 
problem.

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Edward K. Ream]

On Friday, July 14, 2017 at 10:36:30 AM UTC-5, Edward K. Ream wrote:

And there is yet another way to get the message above.  leoPy.leo could be 
> considered a "global variable".  I refactored fc.putVnode in the "persist" 
> branch, deleting one node. After closing leoPy.leo I switched back to 
> master. When I reopened leoPy.leo in the master branch there was a missing 
> reference to the deleted node.
>
> Happily, refresh-from-disk on leoFileCommands.py updated the outline, 
> thereby fixing the problem.
>

This can't be a good sign.  refresh-from-disk should work *exactly* like 
the read code, but apparently not.

There is likely some subtle problem with Leo's read code.  As usual, clones 
are a prime suspect.

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Edward K. Ream]

On Monday, July 10, 2017 at 10:05:54 AM UTC-5, Edward K. Ream wrote:

And I just came across another danger.  If I have written a file in master, 
> I have also written it to *master's* cache.  Doing git branch -b doesn't 
> clear that cache.
>
> As a result, on several occasions I have gotten this:
> Internal Leo error in checkForChangedNodes
>

And there is yet another way to get the message above.  leoPy.leo could be 
considered a "global variable".  I refactored fc.putVnode in the "persist" 
branch, deleting one node. After closing leoPy.leo I switched back to 
master. When I reopened leoPy.leo in the master branch there was a missing 
reference to the deleted node.

Happily, reload-from-disk on leoFileCommands.py updated the outline, 
thereby fixing the problem.

Perhaps I should be using a different copy of leoPy.leo for each branch.  
I'm not sure how to do that automatically because leoPy.leo is in 
.gitignore...

Any ideas?

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Edward K. Ream]

On Mon, Jul 10, 2017 at 11:29 PM, Xavier G. Domingo 
wrote:

> El 10/07/2017 a las 12:05, Edward K. Ream escribió:
>

​> ​
So the conclusion is that Leo's caches must be completely cleared
after any *git
stash* or any *git chechout -b* to make them safe?

​Good question.  I think the answer is yes, if you have saved (in master),
changed files that actually belong in the branch.

​> ​
Is this also necessary when doing a simple *git checkout *?

​It's not the git commands that create the problem, it's the saving files
in one branch and then "transferring" those files to another branch.​

In other words, the problem is the "assignment" of code to the wrong
branch *within
Leo's caches*.  Or so I think now ;-)

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Xavier G. Domingo]

El 10/07/2017 a las 12:05, Edward K. Ream escribió:

On Sunday, July 9, 2017 at 1:09:57 AM UTC-5, Edward K. Ream wrote:

*Danger*: *stashing goes back in time in master*. All of Leo's
caches must be completely cleared!


And I just came across another danger.  If I have written a file in 
master, I have also written it to /master's/ cache.  Doing git branch 
-b doesn't clear that cache.


As a result, on several occasions I have gotten this:
Internal Leo error in checkForChangedNodes

A workaround is to clear the cache for the affected .leo file.  Not 
sure what the real solution is.


So the conclusion is that Leo's caches must be completely cleared after 
any *git stash* or any *git chechout -b* to make them safe? Is it?


Is this also necessary when doing a simple *git checkout *?

Xavier

--
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Edward K. Ream]

On Sunday, July 9, 2017 at 1:09:57 AM UTC-5, Edward K. Ream wrote:

*Danger*: *stashing goes back in time in master*. All of Leo's caches must 
> be completely cleared!
>

And I just came across another danger.  If I have written a file in master, 
I have also written it to *master's* cache.  Doing git branch -b doesn't 
clear that cache.

As a result, on several occasions I have gotten this:
Internal Leo error in checkForChangedNodes

A workaround is to clear the cache for the affected .leo file.  Not sure 
what the real solution is.

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Edward K. Ream]

On Sun, Jul 9, 2017 at 10:07 AM, Terry Brown  wrote:

I wouldn't use stash in that case.  For me step three would be
>
> git checkout -b harder_than_i_thought
> git commit -a
>

​Thanks for this.  You can't switch branches with uncommitted work, so I
didn't realize this was possible.

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A road to branch pollution: git stash goes back in time

[Terry Brown]

On Sat, 8 Jul 2017 23:09:57 -0700 (PDT)
"Edward K. Ream"  wrote:

> Here's a common scenario.
> 
> 1. I think a task is going to be easy, so I begin work on it in
> master.
> 
> 2. Oops. The task isn't so easy. I better switch to a new branch.
> 
> 3. No problem, right? Just do git stash, create the branch, and do a
> git stash pop.

I wouldn't use stash in that case.  For me step three would be

git checkout -b harder_than_i_thought
git commit -a

`checkout -b` switches to a new branch, without impacting working tree
files.

Cheers -Terry

> *Danger*: *stashing goes back in time in master*. All of Leo's caches
> must be completely cleared!
> 
> I recommend deleting everything in .leo/db. Not doing this was very
> likely the cause of the bleeds of other branches into master.  Do you
> see?
> 
> Edward
> 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.