You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
git rebase takes a long time to rewrite history, which may start becoming unacceptable for tutorials as large as lua-tutorial. However, large projects like lua tend to be already split up into many files, and if a tutorial only makes changes to one file per step (as I think they should), there's no reason to spend time rewriting the entire git history since there can only be conflicts with other steps that change that one file.
So the git repo would consist of multiple roots/branches, each one referencing the chain of commits that modify one particular file. There would have to be some kind of manifest file somewhere that would specify the order of steps between all the different files, which leg would have to keep track of (I don't think the user would ever want to have to deal with that themselves).
There should still be the option of using the normal git format, and the ability to switch between the two, in case users want a repo they can go in and edit by hand.
The text was updated successfully, but these errors were encountered:
Changing multiple files per step could actually be supported, by having the manifest file map multiple commits to a single step. I'm thining the manifest file would be a text file where each line would describe a step, in order. So each line would have a list of commit hashes that are part of that step.
Also, I think the "normal git format" should be a separate Representation, which can be gotten by running leg export, and imported back in with leg import.
git rebase
takes a long time to rewrite history, which may start becoming unacceptable for tutorials as large as lua-tutorial. However, large projects like lua tend to be already split up into many files, and if a tutorial only makes changes to one file per step (as I think they should), there's no reason to spend time rewriting the entire git history since there can only be conflicts with other steps that change that one file.So the git repo would consist of multiple roots/branches, each one referencing the chain of commits that modify one particular file. There would have to be some kind of manifest file somewhere that would specify the order of steps between all the different files, which
leg
would have to keep track of (I don't think the user would ever want to have to deal with that themselves).There should still be the option of using the normal git format, and the ability to switch between the two, in case users want a repo they can go in and edit by hand.
The text was updated successfully, but these errors were encountered: