{"thread":{"id":"55024","subject":"FW: Bug Report: changes to submodule's files can be silently lost forever","startedAt":"2021-01-21T13:50:32Z","lastAt":"2021-01-21T14:27:25Z","messageCount":2,"participants":["Tim Yorke","Philippe Blain"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"414900","messageId":"PA4PR08MB60967539EC75C9AACC4C46A5A9A10@PA4PR08MB6096.eurprd08.prod.outlook.com","threadId":"55024","inReplyTo":"PA4PR08MB60969AFFD0607BDBE3ACBBE6A9A10@PA4PR08MB6096.eurprd08.prod.outlook.com","subject":"FW: Bug Report: changes to submodule's files can be silently lost forever","fromName":"Tim Yorke","fromEmail":"tyorke@visionrt.com","sentAt":"2021-01-21T13:48:02Z","receivedAt":"2021-01-21T13:50:32Z","isPatch":false,"sender":{"key":"tyorke@visionrt.com","avatar":null},"body":"\n\n\n\nThank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\n- I used the command \"git config submodule.recurse true\" in my top-level repository\n- made a change to a file in a submodule (located within my top-level repository)\n- performed a git checkout in the top-level repository to a commit that didn't have the submodule\n- performed a git checkout in the top-level repository back to a commit that does have the submodule\n\nWhat did you expect to happen? (Expected behavior)\n\nWhen attempting the first checkout (i.e. to a commit without the submodule), I'd expect an warning telling me that the submodule was not up-to-date (uncommited changes). \n\nWhat happened instead? (Actual behavior)\n\nThe changes to the file in the submodule were lost forever without any warning\n\nWhat's different between what you expected and what actually happened?\n\nMy uncommitted changes were silently lost forever, whereas I'd expect either \n- to be warned before I could continue or\n- the uncommited changes to be retained.\n\nAnything else you want to add:\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.29.2.windows.2\ncpu: x86_64\nbuilt from commit: 3464b98ce6803c98bf8fb34390cd150d66e4a0d3\nsizeof-long: 4\nsizeof-size_t: 8\nshell-path: /bin/sh\nuname: Windows 10.0 21292 \ncompiler info: gnuc: 10.2\nlibc info: no libc information available\n$SHELL (typically, interactive shell): <unset>\n\n\n[Enabled Hooks]\n"},{"id":"414902","messageId":"af8020e6-fe8f-1a48-aba9-f3ad9d7084e4@gmail.com","threadId":"55024","inReplyTo":"PA4PR08MB60967539EC75C9AACC4C46A5A9A10@PA4PR08MB6096.eurprd08.prod.outlook.com","subject":"Re: FW: Bug Report: changes to submodule's files can be silently lost forever","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2021-01-21T14:22:50Z","receivedAt":"2021-01-21T14:27:25Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Tim!\n\nLe 2021-01-21 à 08:48, Tim Yorke a écrit :\n\n> What did you do before the bug happened? (Steps to reproduce your issue)\n> \n> - I used the command \"git config submodule.recurse true\" in my top-level repository\n> - made a change to a file in a submodule (located within my top-level repository)\n> - performed a git checkout in the top-level repository to a commit that didn't have the submodule\n> - performed a git checkout in the top-level repository back to a commit that does have the submodule\n> \n> What did you expect to happen? (Expected behavior)\n> \n> When attempting the first checkout (i.e. to a commit without the submodule), I'd expect an warning telling me that the submodule was not up-to-date (uncommited changes). \n\n\nThat's indeed very sensible.\n\n> \n> What happened instead? (Actual behavior)\n> \n> The changes to the file in the submodule were lost forever without any warning\n> \n> What's different between what you expected and what actually happened?\n> \n> My uncommitted changes were silently lost forever, whereas I'd expect either \n> - to be warned before I could continue or\n> - the uncommited changes to be retained.\n>\n\nThanks for the report. This is a known problem ([1], [2], [3]),\nand I'm working on fixing it.\n\nJust to be sure, the changes you lost were to a tracked file in\nthe submodule, right ? It was not a new, untracked file ?\n\nI'm not quite ready yet to submit my fixes, but if you want to compile\nGit from source in the meantime, the heart of the fix is this diff:\n\n\ndiff --git a/unpack-trees.c b/unpack-trees.c index 323280dd48..a3e3d98de1 100644\n--- a/unpack-trees.c\n+++ b/unpack-trees.c\n@@ -1872,7 +1872,7 @@ static int verify_uptodate_1(const struct cache_entry *ce,\n   \n   \t\tif (submodule_from_ce(ce)) {\n   \t\t\tint r = check_submodule_move_head(ce,\n-\t\t\t\t\"HEAD\", oid_to_hex(&ce->oid), o);\n+\t\t\t\t\"HEAD\", empty_tree_oid_hex(), o);\n   \t\t\tif (r)\n   \t\t\t\treturn add_rejected_path(o, error_type, ce->name);\n   \t\t\treturn 0;\n\nThis should prevent Git from switching branches if any tracked files are modified\nin the submodule.\n\nCheers,\n\nPhilippe.\n\n[1] https://lore.kernel.org/git/570e77a07f0b4d4ea09307e5fa819d6f@fiveco.ch/t/#u\n[2] https://lore.kernel.org/git/20200525094019.22padbzuk7ukr5uv@overdrive.tratt.net/\n[3] https://lore.kernel.org/git/CAHsG2VT4YB_nf8PrEmrHwK-iY-AQo0VDcvXGVsf8cEYXws4nig@mail.gmail.com/\n\n"}]}