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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 20, 2026, 01:50 UTC
Message-ID: <xmqqa4uyv1ql.fsf@gitster.g>
In-Reply-To: <27109.13129.424068.382997@chiark.greenend.org.uk>

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

Show 12 quoted lines

> 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.

;-).

> Before I go much further, how do we think this would best be packaged?

My preference is (as it has always been)

 (1) host it somewhere outside of my tree,

 (2) replace contrib/subtree/* with a single file
     contrib/subtree/README that lead people to the new location.

The preference is not limited to subtree but generally applies to things in contrib/. I prefer to see them graduate this project and stand on their own, when they do not have storng dependency on the git-core project. From technical point of view, this is especially true if your plan is to depend on libgit2, as it is not our dependency. Back when Git was very young, it did make sense to have related-but-not-quite-Git things (like gitk and git-gui) shipped to give them visibility, but we have passed that stage 15 years ago.

Thanks.