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

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

Ian Jackson writes ("Re: [PATCH v2 0/3] contrib/subtree: reduce recursion during split"):
> 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.