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

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

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

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

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

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.

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

> > 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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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.

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

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

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

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. *Danger*: *stashing goes back in time in