Re: git-subtree split misbehaviour with a commit having empty ls-tree for the specified subdir

[Ed Maste <emaste@freebsd.org>]

On Tue, 17 Dec 2019 at 19:17, Tom Clarkson <tqclarkson@icloud.com> wrote:
>
> The algorithm I am looking at to replace the file based mainline detection is
>
>  - If subtree root is unknown (as on the initial split), everything is mainline.
>
>  - If subtree root is reachable and mainline root is not, it’s a subtree commit
>
>  - Otherwise, treat as mainline. This will also pick up commits from other subtrees but they hopefully won’t contain the subtree folder. I don’t think there is an unambiguous way to distinguish a subtree merge from a regular merge - the message produced is pretty generic. It may be possible to check reachability of all known subtrees, but that adds a fair bit of complexity.
>
> That leaves us with the question of how to record the empty mainline commits. The most correct result for your repro is probably four commits (add/delete everything/restore/modify), but I can see that falling over in a scenario where deleting a subtree is more like unlinking a library than editing that library to do nothing.
>
> Is it sufficiently correct for your scenario to treat ‘restore file1’ as the initial subtree commit?

My reproduction scenario is really a demonstration of the real issue I
encountered. Running the initial "subtree split" on the real repo
takes about 40 minutes so I wanted something trivial that shows the
same issue. In the demonstration case (i.e., actually removing and
readding the subtree) I think it's reasonable to start with the commit
that added it back.

Overall I think your proposed algorithm is reasonable (even though I
think it won't address some of the cases in our repo). Will your
algorithm allow us to pass $dir to git rev-list, for the initial
split?

My actual issue stems from the way svn2git converted some odd svn
history, and is described in more detail on the freebsd-git mailing
list at https://lists.freebsd.org/pipermail/freebsd-git/2019-November/000218.html.

Perhaps we can have some command-line options to provide metadata for
cases that cannot be inferred? The cases in our repo come from svn2git
creating subtree merges to represent updates from vendor code. AFAIK
these should be basically identical to what subtree creates, except
that we don't have any of the metadata it adds.

For a concrete example (from the repo at
https://github.com/freebsd/freebsd), 7f3a50b3b9f8 is a mainline commit
that added a new subtree, from 9ee787636908. I think that if I could
inform subtree split that 9ee787636908 is the root it would work for
me.