For example, you might be editing a .litdiff file and see a change that needs to be made in step 12. So you run leg edit 12 and it checks out that commit in the repo and copies the working directory to step-12/ and asks you to edit it. You edit it (referring to the original diff in the .litdiff file) and then run leg save to amend the commit. Then a git rebase is done automatically, and if any conflicts come up you will have to handle them one at a time using the same workflow (conflicting commit is copied to step-XX/, you resolve the conflict and then run leg save to continue).
Eventually you might hardly ever have to use git directly to modify the repo, just do everything through leg. When that time comes, the repo/ folder should probably be kept in a .leg/ directory and hidden from the user. Then to the user, there will only be one representation of the tutorial: the .litdiff files. Having one representation will simplify the usage of leg so much, I think multiple representations have always been the thing that makes leg so hard to learn to use.
Update: Yeah. I think I want to hide all git stuff in .leg/ and behind leg commands. leg init would initialize a new git repo and create an empty work directory for you to add your initial file(s) to. leg commit would save the work directory to a new commit (or maybe to an existing commit, depending on context...). The workflow would be really similar to how I first started writing kilo-tutorial using step folders, but way more streamlined and backed directly by git. Yes, this is definitely the way to go.
Commands to implement
[x] leg init
Creates new empty repo in .leg/repo and empty step/ folder
[x] leg step <step-number>
Checks out step commit into step/ folder
leg <step-number> should be a shortcut for this
[x] leg amend
Rewrites currently checked-out step with the contents of step/
[x] leg commit
Inserts a new step after the current one, with the contents of step/, making that the current step
[x] leg save
Saves changes made by leg amend and/or leg commit, by rebasing
Actually I think amend and commit should rebase automatically most of the time, but there should be a way to stop it from doing that until you manually run leg save...
[x] leg resolve
During a conflict, marks files in step/ as resolved and continues the rebase
[ ] leg split <step-number>
Similar to leg step, but checks out the previous step into step/, and the actual step into final/ (?), and you are expected to do one or more leg commits, and then on leg save the actual step will be replaced the result of committing final/ (if it differs from your latest commit)
[ ] leg squash <start-step-number> <end-step-number>
Squashes the given range of steps into one step (git rebase should always be able to do this successfully)
[ ] leg move <from-step-number> <to-step-number>
Reorders a step to go before the given target step number, by rebasing
[x] leg reset
Aborts any rebase that might be in progress, removes any checked-out folders, and checks out the top-most step.
[x] leg diff
Runs git diff to show the changes you've made to the currently checked-out step in step/
[x] leg status
Shows you what step your have checked out, and whether you have unresolved conflicts or a pending rebase.
For example, you might be editing a
.litdifffile and see a change that needs to be made in step 12. So you runleg edit 12and it checks out that commit in the repo and copies the working directory tostep-12/and asks you to edit it. You edit it (referring to the original diff in the.litdifffile) and then runleg saveto amend the commit. Then a git rebase is done automatically, and if any conflicts come up you will have to handle them one at a time using the same workflow (conflicting commit is copied tostep-XX/, you resolve the conflict and then runleg saveto continue).Eventually you might hardly ever have to use git directly to modify the repo, just do everything through leg. When that time comes, the
repo/folder should probably be kept in a.leg/directory and hidden from the user. Then to the user, there will only be one representation of the tutorial: the.litdifffiles. Having one representation will simplify the usage oflegso much, I think multiple representations have always been the thing that makeslegso hard to learn to use.Update: Yeah. I think I want to hide all git stuff in
.leg/and behindlegcommands.leg initwould initialize a new git repo and create an empty work directory for you to add your initial file(s) to.leg commitwould save the work directory to a new commit (or maybe to an existing commit, depending on context...). The workflow would be really similar to how I first started writing kilo-tutorial using step folders, but way more streamlined and backed directly by git. Yes, this is definitely the way to go.Commands to implement
leg init.leg/repoand emptystep/folderleg step <step-number>step/folderleg <step-number>should be a shortcut for thisleg amendstep/leg commitstep/, making that the current stepleg saveleg amendand/orleg commit, by rebasingamendandcommitshould rebase automatically most of the time, but there should be a way to stop it from doing that until you manually runleg save...leg resolvestep/as resolved and continues the rebaseleg split <step-number>leg step, but checks out the previous step intostep/, and the actual step intofinal/(?), and you are expected to do one or moreleg commits, and then onleg savethe actual step will be replaced the result of committingfinal/(if it differs from your latestcommit)leg squash <start-step-number> <end-step-number>leg move <from-step-number> <to-step-number>leg resetleg diffgit diffto show the changes you've made to the currently checked-out step instep/leg status