On Tue, Dec 26, 2023 at 1:58 AM Eli Schwartz [off-list ref] 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/ (local)

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