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

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
Date: Apr 20, 2026, 09:57 UTC
Message-ID: <27109.63619.90318.366157@chiark.greenend.org.uk>
In-Reply-To: <27109.13129.424068.382997@chiark.greenend.org.uk>

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

Show 11 quoted lines

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

This last part turns out to be false.

It is only `git-subtree add` that puts this metadata in the commit message; `git-subtree merge` doesn't. This makes it very hard to distinguish a subtree merge from (say) a merge of a branch that predates the subtree add.

I need to think about this some more but I doubt this can be made to work well without more significant changes, including to the data model. There would have to be some kind of compatibility arrangement to handle existing histories.

Colin, is that OK with you? If you would prefer, I could choose a different name for the resulting program. My preference would be, with your consent, to continue to call it "git-subtree", version 2.

Regards, Ian.

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