Skip to content
This repository has been archived by the owner on Aug 28, 2020. It is now read-only.

Workflow for merging leoAst and ast-token-tools 'branches' #8

Open
maphew opened this issue Jan 18, 2020 · 1 comment
Open

Workflow for merging leoAst and ast-token-tools 'branches' #8

maphew opened this issue Jan 18, 2020 · 1 comment

Comments

@maphew
Copy link
Member

maphew commented Jan 18, 2020

Now and for an indeterminate length into the future, primary development of this toolkit is occuring within the arms of Leo Editor project. Presumably at some point the locus will shift to ast-token-tools. Regardless of where the activity centre is, the two need to kept in sync. This issue is about devising/capturing/documenting that workflow, and keeping it simple as possible so it's actually used.

Part 1: the initial import of leoAst.py was done using ./tools/git-copy.sh. The script creates a git patch file from one repo (e.g. leo-editor) and then applies the patch to another repo (ast-token-tools). The effect is the file or folder now exists in the destination repo with it's entire commit history intact.

I don't understand how it works, just that it does. Presumably merging in future patch sets will necessitate adapting the script or creating a new one so that subsequent 'merges' aren't duplicating history. (Or maybe git is just smart enough on it's own and we don't need to change anything!)

maphew added a commit that referenced this issue Jan 18, 2020
in support of #8, describing cross-repo merge workflow
@maphew
Copy link
Member Author

maphew commented Jan 18, 2020

Attempted a test to see if git will just take care of it and ran into an issue.

Mingw git console via Git Extensions:

cd ~
pushd code/leo-editor
git checkout fstrings
git pull
../ast-token-tools/tools/git-copy.sh leo/core/leoAst.py ../ast-token-tools/ast_token_tools/
creating patch for path leo/core/leoAst.py
moving to destination repo at ../ast-token-tools/ast_token_tools/
applying patch
error: unknown option `first-parent'
...snip...

This machine is git version 2.20.1.windows.1. I've read that first-parent was added in v1.84. I didn't have this error previously, but I was on another machine.

...
I removed first-parent and ran again. This time import was successful, however history is duplicated so, so yes we'll need to find the last commit in common and then create a patch only for what's new. Next up: search for prior art doing this.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant