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

[Ben Knoble <ben.knoble@gmail.com>]

I didn’t see bmc on cc, so added. I think they have some thoughts on how to organize Rust code with Git. Might be relevant, even though this is contrib/

> 
> Le 19 avr. 2026 à 15:56, Ian Jackson <ijackson@chiark.greenend.org.uk> a écrit :
> 
> 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.
>