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

[Christian Couder <christian.couder@gmail.com>]

On Tue, Dec 26, 2023 at 1:58 AM Eli Schwartz <eschwartz93@gmail.com> wrote:
>
> 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).

Thanks for reporting this issue! Unfortunately it looks like git
subtree is not very well maintained these days.

There is another thread where Zach FettersMoore proposed other fixes
in what look like a similar area:

https://lore.kernel.org/git/pull.1587.v6.git.1701442494319.gitgitgadget@gmail.com/

Maybe you could team up with Zach to review each other's fixes?