Re: Regression in git-subtree.sh, introduced in 2.20.1, after 315a84f9aa0e2e629b0680068646b0032518ebed

[Tom Clarkson <tqclarkson@icloud.com>]

> On 16 Dec 2019, at 10:30 pm, Ed Maste <emaste@freebsd.org> wrote:
> 
> On Sat, 14 Dec 2019 at 09:27, Tom Clarkson <tqclarkson@icloud.com> wrote:
>> 
>> When you say it pushed every commit, does that mean that a bunch of mainline commits erroneously ended up in the subtree repo?
> 
> We encounter this case when trying to use subtree on the FreeBSD
> repository. In our case it's caused by commit that should not be
> classified as a commit to the subtree, but has no files in the
> subtree. In our case it looks like an artifact of svn-git conversion
> of an odd working branch, but the same issue is reproducible in other
> ways. For example, it will appear if the subtree is deleted at some
> point and later re-added.

Deleting and re-adding a subtree is an interesting case. My patch won’t avoid the recursion there, because it can only be certain about the irrelevance of commits from before the first add.

However, I think that may be ok to leave in as something of an edge case - you may get more recursion than your system can handle, but assuming process_split_commit is correct, you can work around it by increasing ulimit, and can avoid any subsequent performance issues with a rejoin commit. Maybe we could display some sort of “your repo is doing something weird” warning to make it clearer where there are problems to be worked around.

Although the recursion would no doubt fall over on pretty much any machine when depth gets to 200k, it looks like the FreeBSD repo isn’t getting to that point, so let’s  cover the details of more reliable mainline detection on its own thread.