threads / discuss / 60656

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

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

## tl;dr

2 messages between Dec 26, 2023 and Jan 2, 2024.

replies: 1people: 2as markdown or json

Eli Schwartz· Dec 26, 2023, 00:58 UTC · lore

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

Christian Couder· Jan 2, 2024, 18:23 UTC · re: Eli Schwartz · lore

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

On Tue, Dec 26, 2023 at 1:58 AM Eli Schwartz <eschwartz93@gmail.com> wrote:

Show 41 quoted lines

>
> 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?