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

From: Eli Schwartz <eschwartz93@gmail.com>
Date: Dec 26, 2023, 00:58 UTC
Message-ID: <6de00946-9c5a-4854-9e49-069a22f8a782@gmail.com>

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