search

langfield / ki

version control for Anki collections
https://langfield.github.io/ki/
GNU Affero General Public License v3.0
74 stars 3 forks source link

On the use of `git` submodules #125

Closed langfield closed 1 year ago

langfield commented 1 year ago

Should we make submodule.py a ki subcommand? ~They might not want a remote at all, so probably best to remove it.~ The way submodules works makes this a bad idea. Don't do this.

It is also unclear if this should be a core ki command. It relies on some functions in __init__.py, as well as bindings to git-filter-repo, so a Haskell port will be a bit nontrivial. However, it does seem like a pretty important thing. 🤷🏻‍♀️

langfield commented 1 year ago

Yes, it should probably be a ki command. Some possible names:

langfield commented 1 year ago

It is definitely kind of annoying to have to call this from the cloned ki repository.

langfield commented 1 year ago

Maybe this should be called subdeck?

Instead of having submodules in ki repositories, instead we could have a subdecks directory that is in the gitignore. For each deck that we want tracked on github, we have a directory called deck1, deck2, etc. These are git repositories, but they're purely local, and as I said, not submodules or subrepos or anything. Completely separate. When we've pulled changes into our FLAT ki repository, we have a make recipe that dirty-copies all the data from the deck1 directory in the ki repository into the deck1 subdirectory under subdecks/. Then it adds these changes and commits them. So it probably just computes a patch or something and applies the patch (so we get deletions as well). Then the user has another deck1 repo somewhere on their machine, and this one has 2 remotes. The first is the ordinary one, which they can use to push to github or whatever. The second points to the subdecks/deck1 repo in the ki repository root directory, and this is where they pull changes from.

To push changes back up to the ki repository from the local copy of deck1...

  1. Pull latest changes from the ki repository into the subdeck via a patch. We can compute the correct revision to diff against by storing a tag. Then we can do diff <tag> HEAD -- <subdeck>. Call this .

  2. Pull changes from subdeck to the local copy (call this ), then push changes back to the subdeck (so now exists in the subdeck repo).

  3. Compute a patch from the to , and copy those changes and commit them in the ki repo.

langfield commented 1 year ago

They're gone! 😁