Re: [PATCH v2 0/3] contrib/subtree: reduce recursion during split

Colin Stagner writes ("Re: [PATCH v2 0/3] contrib/subtree: reduce recursion during split"):

I prototyped something along the lines of the algorithm I described earlier. It is very fast, as expected.

The output looks plausible when I look at it by eye, but there are some things that I need to look at more closely. I should think some more about invariants and tests.

Overall, I think this is worth pursuing.

Algorithm

I don't think it is going to be possible to precisely reproduce the output of the existing git-subtree split. Indeed the existing git-subtree split is a bit cavalier with metadata (eg `committer` [1]) which probably ought to be changed in any case.

Even so, it should be possible to avoid foolishly rewriting the whole history of the subtree, since we can stop at all the merges made by "git-subtree merge", which are easily detectable by the extra metadata keyword fields in the commit message.

Packaging

Before I go much further, how do we think this would best be packaged? Currently my experiment is a standalone Rust package using dependencies ("crates" as Rust calls thme) from current Debian stable ("trixie"). [2] I haven't tried it with recent deps from upstream crates.io. There is not currently any entanglement with git.git; the repository is accessed using libgit2 via Rust's git2 wrapper (and there are no tests yet).

I'm tempted to continue this way and rewrite the other git-subtree subcommands too, since they don't look that hard. Using git.git offers some packaging and testing continuity but the dependency situation might become annoying.

It will probably be possible to make a Rust package which will build with both recent upstream dependencies, and (say) Debian stable. Going back much more than that is going to be awkward.

I see there's already some Rust in git.git:contrib/libgit-rs but that looks like a poc.

Regards, Ian.

[1] I don't think it's justifiable to convert a commit from the
downstream, into the subtree split version, and retain the original
committer line.  That can violate many people's expectations.
Here's an example from another context:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1124226

That means we need to use a dummy committer in split commits, and put the original committer into the message. We should name the original downstream commit in the commit message too.

The dummy committer needs to be a fixed string: changing it would cause history proliferation (maybe even leading to unnecessary merge conflicts).

[2] I wrote a blog post

   How to use Rust on Debian (and Ubuntu, etc.)
   https://diziet.dreamwidth.org/18122.html

which explains why this is a good approach.