Create various step-editing commands that are thin but helpful wrappers over git commands

[paigeruten]

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

• leg init
  • Creates new empty repo in .leg/repo and empty step/ folder
• leg step <step-number>
  • Checks out step commit into step/ folder
  • leg <step-number> should be a shortcut for this
• leg amend
  • Rewrites currently checked-out step with the contents of step/
• leg commit
  • Inserts a new step after the current one, with the contents of step/, making that the current step
• 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...
• 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
• leg reset
  • Aborts any rebase that might be in progress, removes any checked-out folders, and checks out the top-most step.
• leg diff
  • Runs git diff to show the changes you've made to the currently checked-out step in step/
• leg status
  • Shows you what step your have checked out, and whether you have unresolved conflicts or a pending rebase.