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

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Colin Stagner writes ("Re: [PATCH v2 0/3] contrib/subtree: reduce recursion during split"):
> That said, a native Rust version of 
> git-subtree-split would be much faster and easier to read.

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.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.