Re: subtree split after deleting and re-running git-subtree add, fails with "fatal: cache for XXX already exists!"

>
> Originally reported in https://github.com/eli-schwartz/aurpublish/issues/30
>
>
> Given a subtree that gets messed up, some users might naturally
> gravitate towards deleting the subtree, and recreating it again via
> `git subtree add`. This can result in a difficult to solve situation.
> Any attempt to split it seems to produce failure.
>
> Reproducer:
>
> git init testme && cd testme
> mkdir foo
> touch foo/bar
> git add foo/bar
> git commit -m ...
> split_commit=$(git subtree split -P foo --rejoin)
> # Added dir 'foo'
> echo "${split_commit}"
> # 42517e4b9fe310a64be2a777ef08c91bd582b385
>
> git rm -r foo
> git commit -m deleted
> git subtree add --prefix foo "${split_commit}"
> # Added dir 'foo'
> git subtree split -P foo --rejoin
> # fatal: cache for 42517e4b9fe310a64be2a777ef08c91bd582b385 already exists!
>
>
>
> The interesting thing here is that in git.git commit
> d2f0f819547de35ffc923fc963f806f1656eb2ca:
> "subtree: more consistent error propagation"
> the git-subtree program got a bit of a facelift w.r.t. proper error
> checking.
>
> In particular, in find_existing_splits, `cache_set $sub $sub` will fail
> here. But before that commit, the die did not propagate. It turns out
> that actually ignoring this was "fine" and resulted in successfully
> splitting (while also printing a "warning": back then, the word "fatal"
> did not appear anywhere in the message; now it does).