{"thread":{"id":"60656","subject":"subtree split after deleting and re-running git-subtree add, fails with \"fatal: cache for XXX already exists!\"","startedAt":"2023-12-26T00:58:18Z","lastAt":"2024-01-02T18:24:03Z","messageCount":2,"participants":["Eli Schwartz","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"486023","messageId":"6de00946-9c5a-4854-9e49-069a22f8a782@gmail.com","threadId":"60656","inReplyTo":null,"subject":"subtree split after deleting and re-running git-subtree add, fails with \"fatal: cache for XXX already exists!\"","fromName":"Eli Schwartz","fromEmail":"eschwartz93@gmail.com","sentAt":"2023-12-26T00:58:14Z","receivedAt":"2023-12-26T00:58:18Z","isPatch":false,"sender":{"key":"eschwartz93@gmail.com","avatar":"https://gravatar.com/avatar/80b459bb75c0edb5e116884705adb9095fbd01cbbf91cb29a9ed23577fff7d34?d=mp&s=160"},"body":"Originally reported in https://github.com/eli-schwartz/aurpublish/issues/30\n\n\nGiven a subtree that gets messed up, some users might naturally\ngravitate towards deleting the subtree, and recreating it again via\n`git subtree add`. This can result in a difficult to solve situation.\nAny attempt to split it seems to produce failure.\n\nReproducer:\n\ngit init testme && cd testme\nmkdir foo\ntouch foo/bar\ngit add foo/bar\ngit commit -m ...\nsplit_commit=$(git subtree split -P foo --rejoin)\n# Added dir 'foo'\necho \"${split_commit}\"\n# 42517e4b9fe310a64be2a777ef08c91bd582b385\n\ngit rm -r foo\ngit commit -m deleted\ngit subtree add --prefix foo \"${split_commit}\"\n# Added dir 'foo'\ngit subtree split -P foo --rejoin\n# fatal: cache for 42517e4b9fe310a64be2a777ef08c91bd582b385 already exists!\n\n\n\nThe interesting thing here is that in git.git commit\nd2f0f819547de35ffc923fc963f806f1656eb2ca:\n\"subtree: more consistent error propagation\"\nthe git-subtree program got a bit of a facelift w.r.t. proper error\nchecking.\n\nIn particular, in find_existing_splits, `cache_set $sub $sub` will fail\nhere. But before that commit, the die did not propagate. It turns out\nthat actually ignoring this was \"fine\" and resulted in successfully\nsplitting (while also printing a \"warning\": back then, the word \"fatal\"\ndid not appear anywhere in the message; now it does).\n\nAs a quick hack, this seems to restore things:\n\n```\n@@ -499,7 +505,7 @@ find_existing_splits () {\n                        then\n                                debug \"  Prior: $main -> $sub\"\n                                cache_set $main $sub\n-                               cache_set $sub $sub\n+                               (cache_set $sub $sub) || true\n                                try_remove_previous \"$main\"\n                                try_remove_previous \"$sub\"\n                        fi\n```\n\nSo:\n\n\n$ PATH=/home/eschwartz/git/git/contrib/subtree/:$PATH git subtree.sh\nsplit -P foo\nfatal: cache for 5f662c163282b3657604c789ae639a98c211d5a7 already exists!\n5f662c163282b3657604c789ae639a98c211d5a7\n$ echo $?\n0\n```\n\n\nThoughts on fixing this properly? I haven't looked at the implementation\nbefore so maybe there's a better algorithm for handling this. I suppose\nI could submit a patch that adds a `_cache_set` for cases where you want\nto allow duplicates, and use it here.\n\n\n-- \nEli Schwartz\n"},{"id":"486203","messageId":"CAP8UFD3bSRCJgomOSYteJrvXEABwJFnhXu=0qg-ORq680N2j7A@mail.gmail.com","threadId":"60656","inReplyTo":"6de00946-9c5a-4854-9e49-069a22f8a782@gmail.com","subject":"Re: subtree split after deleting and re-running git-subtree add, fails with \"fatal: cache for XXX already exists!\"","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2024-01-02T18:23:49Z","receivedAt":"2024-01-02T18:24:03Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Dec 26, 2023 at 1:58 AM Eli Schwartz <eschwartz93@gmail.com> wrote:\n>\n> Originally reported in https://github.com/eli-schwartz/aurpublish/issues/30\n>\n>\n> Given a subtree that gets messed up, some users might naturally\n> gravitate towards deleting the subtree, and recreating it again via\n> `git subtree add`. This can result in a difficult to solve situation.\n> Any attempt to split it seems to produce failure.\n>\n> Reproducer:\n>\n> git init testme && cd testme\n> mkdir foo\n> touch foo/bar\n> git add foo/bar\n> git commit -m ...\n> split_commit=$(git subtree split -P foo --rejoin)\n> # Added dir 'foo'\n> echo \"${split_commit}\"\n> # 42517e4b9fe310a64be2a777ef08c91bd582b385\n>\n> git rm -r foo\n> git commit -m deleted\n> git subtree add --prefix foo \"${split_commit}\"\n> # Added dir 'foo'\n> git subtree split -P foo --rejoin\n> # fatal: cache for 42517e4b9fe310a64be2a777ef08c91bd582b385 already exists!\n>\n>\n>\n> The interesting thing here is that in git.git commit\n> d2f0f819547de35ffc923fc963f806f1656eb2ca:\n> \"subtree: more consistent error propagation\"\n> the git-subtree program got a bit of a facelift w.r.t. proper error\n> checking.\n>\n> In particular, in find_existing_splits, `cache_set $sub $sub` will fail\n> here. But before that commit, the die did not propagate. It turns out\n> that actually ignoring this was \"fine\" and resulted in successfully\n> splitting (while also printing a \"warning\": back then, the word \"fatal\"\n> did not appear anywhere in the message; now it does).\n\nThanks for reporting this issue! Unfortunately it looks like git\nsubtree is not very well maintained these days.\n\nThere is another thread where Zach FettersMoore proposed other fixes\nin what look like a similar area:\n\nhttps://lore.kernel.org/git/pull.1587.v6.git.1701442494319.gitgitgadget@gmail.com/\n\nMaybe you could team up with Zach to review each other's fixes?\n"}]}