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

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

[Eli Schwartz]

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).

As a quick hack, this seems to restore things:

```
@@ -499,7 +505,7 @@ find_existing_splits () {
                        then
                                debug "  Prior: $main -> $sub"
                                cache_set $main $sub
-                               cache_set $sub $sub
+                               (cache_set $sub $sub) || true
                                try_remove_previous "$main"
                                try_remove_previous "$sub"
                        fi
```

So:


$ PATH=/home/eschwartz/git/git/contrib/subtree/:$PATH git subtree.sh
split -P foo
fatal: cache for 5f662c163282b3657604c789ae639a98c211d5a7 already exists!
5f662c163282b3657604c789ae639a98c211d5a7
$ echo $?
0
```


Thoughts on fixing this properly? I haven't looked at the implementation
before so maybe there's a better algorithm for handling this. I suppose
I could submit a patch that adds a `_cache_set` for cases where you want
to allow duplicates, and use it here.


-- 
Eli Schwartz

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

[Christian Couder]

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?