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
