I find that I can't remember what state extra untracked files are in for very long. I usually need to stash them when I update some branch, like devel - git makes me do it before it will let me merge changes from, say, the devel branch in Leo's repo. Pretty soon I lose track of their status. So mostly I don't do that any more. I foresee having the same problems with a private LeoPy.leo outline.
Usually, I use a freshly-updated branch - not devel - private to my own repo for development or experimental work. I update it as close to submitting a PR as possible. Any changes I make to LeoPyRef.leo can get walked back or even reset if need be. This way I feel safe in that I won't be accidentally modifying the "real" LeoPyRef. If I were to get stuck somehow so that my own branch got too far out of sync and couldn't be merged, I would probably copy the external files I changed somewhere outside my repo, then update to the current devel version, then restore my changes from the temporary location. With any luck, that won't happen, but operator error is always possible so who knows? On Tuesday, December 6, 2022 at 1:57:47 PM UTC-5 vitalije wrote: > Have you tried commands `set-reference-file`, `update-ref-file` and > `read-ref-file` instead? > > In all of my projects, nowadays, I have public <project>-ref.leo and > private <project>.leo pair of files. Inside the private Leo file, I set > the reference file to be public <project>-ref.leo file. At the same time > inside public Leo file, I have defined a button node with the headline > `@button > n-save @key=Ctrl-s` and the body like this: > > c.save() > # if using @bool tree-declutter = True uncomment next line > # clean_uas() > c.fileCommands.save_ref() > > Now, every time I press Ctrl-s to save the outline, public outline is > updated accordingly. After executing `git pull` , I open my private outline > and execute mini buffer command `read-ref-file` to synchronize private > outline with the public one. After that I continue to work on my project > using only private outline. > > I don't really have collaborators to work on my projects, so I can't say > that this setup has been battle tested. Sometimes I work on different > machines and I haven't noticed any problem synchronizing work using this > method. I haven't seen unexpectedly big diffs either. > > HTH Vitalije > > On Monday, December 5, 2022 at 2:30:05 PM UTC+1 Edward K. Ream wrote: > >> LeoPyRef.leo defines this button. The button does the following: >> >> - Check that the button is running from leoPy.leo, not LeoPyRef.leo. >> - Updates LeoPyRef.leo using only specific subtrees of leoPy.leo. >> >> Félix and I have noticed that sometimes this script creates large diffs >> between the old and new versions of LeoPyRef.leo. >> >> Instead, the following workflow seems to work better for me: >> >> - Save leoPy.leo as LeoPyRef.leo. >> - Load the new LeoPyRef.leo. >> - Delete unwanted parts of the new LeoPyRef.leo. >> - Execute the git-diff command within LeoPyRef.leo. >> >> The git-diff command will ensure I've not deleted too much :-) >> >> More importantly, the Leonine git-diff shows me the "real" diffs, >> regardless of "extraneous" diffs caused by moving/alphabetizing nodes. >> >> *Summary* >> >> `@button write-leoPyRef` seems buggy in hard-to-pin-down ways. >> >> Updating LeoPyRef.leo "by hand" is safe, provided one checks the work >> using Leo's git-diff command. >> >> Your comments, please. >> >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/aec99888-57e5-4fec-b621-f1e92f654bf8n%40googlegroups.com.
