{"thread":{"id":"56040","subject":"bug in \"git fsck\"?","startedAt":"2021-07-02T14:01:12Z","lastAt":"2021-07-08T16:36:40Z","messageCount":13,"participants":["Ulrich Windl","Junio C Hamano","René Scharfe","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"429049","messageId":"60DF1C22020000A100042225@gwsmtp.uni-regensburg.de","threadId":"56040","inReplyTo":null,"subject":"bug in \"git fsck\"?","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2021-07-02T14:01:06Z","receivedAt":"2021-07-02T14:01:12Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"Hi!\n\n\nI was wondering whether git fsck should be able to cleanup orphaned branches (\"HEAD points to an unborn branch\") as described in https://stackoverflow.com/q/68226081/6607497\nIt seems I can fix it be editing files in the repository, but I feed that's not the way it should be.\n\n\nRegards,\nUlrich\n\n"},{"id":"429064","messageId":"xmqqczs0popg.fsf@gitster.g","threadId":"56040","inReplyTo":"60DF1C22020000A100042225@gwsmtp.uni-regensburg.de","subject":"Re: bug in \"git fsck\"?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-02T18:15:07Z","receivedAt":"2021-07-02T18:15:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Ulrich Windl\" writes:\n\n> I was wondering whether git fsck should be able to cleanup\n> orphaned branches (\"HEAD points to an unborn branch\") as described\n> in https://stackoverflow.com/q/68226081/6607497 It seems I can fix\n> it be editing files in the repository, but I feed that's not the\n> way it should be.\n\nHEAD pointing at an unborn branch is not even a corruption, isn't\nit?\n\n $ rm -rf trash && git init trash\n\nwould point HEAD at an unborn one, ready to be used.\n"},{"id":"429134","messageId":"52847a99-db7c-9634-b3b1-fd9b1342bc32@web.de","threadId":"56040","inReplyTo":"xmqqczs0popg.fsf@gitster.g","subject":"Re: bug in \"git fsck\"?","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2021-07-03T20:03:25Z","receivedAt":"2021-07-03T20:03:33Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 02.07.21 um 20:15 schrieb Junio C Hamano:\n> \"Ulrich Windl\" writes:\n>\n>> I was wondering whether git fsck should be able to cleanup\n>> orphaned branches (\"HEAD points to an unborn branch\") as described\n>> in https://stackoverflow.com/q/68226081/6607497 It seems I can fix\n>> it be editing files in the repository, but I feed that's not the\n>> way it should be.\n>\n> HEAD pointing at an unborn branch is not even a corruption, isn't\n> it?\n>\n> $ rm -rf trash && git init trash\n>\n> would point HEAD at an unborn one, ready to be used.\n\nTrue, but the scenario described on StackOverflow is a bit different.\nCommits were filtered out, and branches still pointing to them cannot\nbe deleted with \"git branch -d\" or \"git branch -D\". Git fsck only\nreports them.\n\nYou *can* overwrite them using \"git branch --force foo\" and then\n\"git branch -d foo\" works.\n\nI think it makes sense to let \"git branch -D foo\" work directly in such\na case. That would be a user-visible change that may cause data loss,\nso we better be careful. I can't imagine a practical data-loss\nscenario, but that might be just me. Under which circumstances do we\nwant to keep a branch that does not point to a commit?\n\nAnyway, here's what the change would look like:\n\n--- >8 ---\nSubject: [PATCH] branch: allow deleting dangling branches with --force\n\ngit branch only allows deleting branches that point to valid commits.\nSkip that check if --force is given, as the caller is indicating with\nit that they know what they are doing and accept the consequences.\nThis allows deleting dangling branches, which previously had to be\nreset to a valid start-point using --force first.\n\nSigned-off-by: René Scharfe \n---\n Documentation/git-branch.txt | 3 ++-\n builtin/branch.c | 2 +-\n t/t3200-branch.sh | 7 +++++++\n 3 files changed, 10 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\nindex 94dc9a54f2..5449767121 100644\n--- a/Documentation/git-branch.txt\n+++ b/Documentation/git-branch.txt\n@@ -118,7 +118,8 @@ OPTIONS\n \tReset to , even if exists\n \talready. Without `-f`, 'git branch' refuses to change an existing branch.\n \tIn combination with `-d` (or `--delete`), allow deleting the\n-\tbranch irrespective of its merged status. In combination with\n+\tbranch irrespective of its merged status, or whether it even\n+\tpoints to a valid commit. In combination with\n \t`-m` (or `--move`), allow renaming the branch even if the new\n \tbranch name already exists, the same applies for `-c` (or `--copy`).\n\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex b23b1d1752..03c7b7253a 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -168,7 +168,7 @@ static int check_branch_commit(const char *branchname, const char *refname,\n \t\t\t int kinds, int force)\n {\n \tstruct commit *rev = lookup_commit_reference(the_repository, oid);\n-\tif (!rev) {\n+\tif (!force && !rev) {\n \t\terror(_(\"Couldn't look up commit object for '%s'\"), refname);\n \t\treturn -1;\n \t}\ndiff --git a/t/t3200-branch.sh b/t/t3200-branch.sh\nindex cc4b10236e..ec61a10c29 100755\n--- a/t/t3200-branch.sh\n+++ b/t/t3200-branch.sh\n@@ -1272,6 +1272,13 @@ test_expect_success 'attempt to delete a branch merged to its base' '\n \ttest_must_fail git branch -d my10\n '\n\n+test_expect_success 'branch --delete --force removes dangling branch' '\n+\ttest_when_finished \"rm -f .git/refs/heads/dangling\" &&\n+\techo $ZERO_OID >.git/refs/heads/dangling &&\n+\tgit branch --delete --force dangling &&\n+\ttest_path_is_missing .git/refs/heads/dangling\n+'\n+\n test_expect_success 'use --edit-description' '\n \twrite_script editor <<-\\EOF &&\n \t\techo \"New contents\" >\"$1\"\n--\n2.32.0\n"},{"id":"429184","messageId":"60E2B04B020000A100042291@gwsmtp.uni-regensburg.de","threadId":"56040","inReplyTo":"xmqqczs0popg.fsf@gitster.g","subject":"Antw: [EXT] Re: bug in \"git fsck\"?","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2021-07-05T07:10:03Z","receivedAt":"2021-07-05T07:10:12Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":">>> Junio C Hamano schrieb am 02.07.2021 um 20:15 in\nNachricht\n:\n> \"Ulrich Windl\" writes:\n> \n>> I was wondering whether git fsck should be able to cleanup\n>> orphaned branches (\"HEAD points to an unborn branch\") as described\n>> in https://stackoverflow.com/q/68226081/6607497 It seems I can fix\n>> it be editing files in the repository, but I feed that's not the\n>> way it should be.\n> \n> HEAD pointing at an unborn branch is not even a corruption, isn't\n> it?\n> \n> $ rm ‑rf trash && git init trash\n> \n> would point HEAD at an unborn one, ready to be used.\n\n\nOK, so maybe I was just confused by \"fsck\". At it seems after committing, fsck\nno longer complains.\nAs \"EXTRACTED DIAGNOSTICS\" In man git-fsck (Git 2.26.2) does not mention\n\"unborn\" (and as it's not a common IT phrase), one could probably explain what\nit means.\n\nRegards,\nUlrich\n\n\n\n"},{"id":"429186","messageId":"60E2B2AF020000A100042296@gwsmtp.uni-regensburg.de","threadId":"56040","inReplyTo":"xmqqczs0popg.fsf@gitster.g","subject":"Antw: [EXT] Re: bug in \"git fsck\"?","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2021-07-05T07:20:15Z","receivedAt":"2021-07-05T07:20:21Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":">>> Ulrich Windl schrieb am 05.07.2021 um 09:10 in Nachricht <60E2B04B.461 :\n161 :\n60728>:\n>>>> Junio C Hamano schrieb am 02.07.2021 um 20:15 in\nNachricht\n> :\n> > \"Ulrich Windl\" writes:\n> > \n> >> I was wondering whether git fsck should be able to cleanup\n> >> orphaned branches (\"HEAD points to an unborn branch\") as described\n> >> in https://stackoverflow.com/q/68226081/6607497 It seems I can fix\n> >> it be editing files in the repository, but I feed that's not the\n> >> way it should be.\n> > \n> > HEAD pointing at an unborn branch is not even a corruption, isn't\n> > it?\n> > \n> > $ rm ‑rf trash && git init trash\n> > \n> > would point HEAD at an unborn one, ready to be used.\n> \n> \n> OK, so maybe I was just confused by \"fsck\". At it seems after committing, \n> fsck no longer complains.\n\nSorry, I didn't think (still pre-coffeine time):\nThe problem is gone in the workspace so far, not in the repository, and I\nthink the problem never was present in the workspace.\nAlso \"git branch\" dispalys three branches in addition to \"master\", while the\n\"branches\" directory of the repository is empty.\nSo when I try to delete a branch displayed by \"git branch\", I get:\nfatal: Couldn't look up commit object for HEAD\n\nIt seems the delete command reads those refs from HEAD:\nref: refs/heads/name_of_branch_to_be_deleted\n\nbut in refs/heads/ that name does not exist\n\nLast command before error message is:\nlstat(\"./objects/00/00000000000000000000000000000000000000\", 0x7fff76d9a180) =\n-1 ENOENT (No such file or directory)\nwrite(2, \"fatal: Couldn't look up commit o\"..., 47fatal: Couldn't look up\ncommit object for HEAD\n) = 47\n\n\n> As \"EXTRACTED DIAGNOSTICS\" In man git-fsck (Git 2.26.2) does not mention \n> \"unborn\" (and as it's not a common IT phrase), one could probably explain \n> what it means.\n> \n> Regards,\n> Ulrich\n> \n> \n> \n> \n\n\n\n"},{"id":"429188","messageId":"87fswt6wxb.fsf@evledraar.gmail.com","threadId":"56040","inReplyTo":"60E2B04B020000A100042291@gwsmtp.uni-regensburg.de","subject":"Re: Antw: [EXT] Re: bug in \"git fsck\"?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-07-05T07:26:49Z","receivedAt":"2021-07-05T07:29:25Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Jul 05 2021, Ulrich Windl wrote:\n\n>>>> Junio C Hamano schrieb am 02.07.2021 um 20:15 in\n> Nachricht\n> :\n>> \"Ulrich Windl\" writes:\n>> \n>>> I was wondering whether git fsck should be able to cleanup\n>>> orphaned branches (\"HEAD points to an unborn branch\") as described\n>>> in https://stackoverflow.com/q/68226081/6607497 It seems I can fix\n>>> it be editing files in the repository, but I feed that's not the\n>>> way it should be.\n>> \n>> HEAD pointing at an unborn branch is not even a corruption, isn't\n>> it?\n>> \n>> $ rm ‑rf trash && git init trash\n>> \n>> would point HEAD at an unborn one, ready to be used.\n>\n>\n> OK, so maybe I was just confused by \"fsck\". At it seems after committing, fsck\n> no longer complains.\n> As \"EXTRACTED DIAGNOSTICS\" In man git-fsck (Git 2.26.2) does not mention\n> \"unborn\" (and as it's not a common IT phrase), one could probably explain what\n> it means.\n\nFWIW you're completely right about the unstated point that fsck's error\nmessages/reporting is pretty bad. I've been trying to fix some of it up\nrecently (including one hopefully soon-to-land series).\n\nIt has a bunch of output that's overly verbose, and other complaints\nwhere it's not clear if they're actionable or not (e.g. what you\nmentioned), or whether it's even a problem.\n\nIf I create an ext4 filesystem and run fsck on it it's not going to\ncomplain that there's no files yet, so it's a bit silly that fsck\ncomplains about a freshly git-init'd repo.\n"},{"id":"429189","messageId":"60E2B7FB020000A1000422A0@gwsmtp.uni-regensburg.de","threadId":"56040","inReplyTo":"52847a99-db7c-9634-b3b1-fd9b1342bc32@web.de","subject":"Antw: [EXT] Re: bug in \"git fsck\"?","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2021-07-05T07:42:51Z","receivedAt":"2021-07-05T07:42:56Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":">>> René Scharfe schrieb am 03.07.2021 um 22:03 in Nachricht\n<52847a99-db7c-9634-b3b1-fd9b1342bc32@web.de>:\n> Am 02.07.21 um 20:15 schrieb Junio C Hamano:\n>> \"Ulrich Windl\" writes:\n>>\n>>> I was wondering whether git fsck should be able to cleanup\n>>> orphaned branches (\"HEAD points to an unborn branch\") as described\n>>> in https://stackoverflow.com/q/68226081/6607497 It seems I can fix\n>>> it be editing files in the repository, but I feed that's not the\n>>> way it should be.\n>>\n>> HEAD pointing at an unborn branch is not even a corruption, isn't\n>> it?\n>>\n>> $ rm -rf trash && git init trash\n>>\n>> would point HEAD at an unborn one, ready to be used.\n> \n> True, but the scenario described on StackOverflow is a bit different.\n> Commits were filtered out, and branches still pointing to them cannot\n> be deleted with \"git branch -d\" or \"git branch -D\". Git fsck only\n> reports them.\n> \n> You *can* overwrite them using \"git branch --force foo\" and then\n> \"git branch -d foo\" works.\n\nWould it be OK to force the branch to any commit (e.g.: \"master\"), relying on\nthe fact that any reference (read: \"master\") to that commit will prevent actual\nremoval of the commit?\n\n"},{"id":"429244","messageId":"77655a4e-8c39-5ccc-71af-d2d8684bf208@web.de","threadId":"56040","inReplyTo":"60E2B7FB020000A1000422A0@gwsmtp.uni-regensburg.de","subject":"Re: Antw: [EXT] Re: bug in \"git fsck\"?","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2021-07-05T14:44:50Z","receivedAt":"2021-07-05T14:44:54Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 05.07.21 um 09:42 schrieb Ulrich Windl:\n>>>> René Scharfe schrieb am 03.07.2021 um 22:03 in Nachricht\n> <52847a99-db7c-9634-b3b1-fd9b1342bc32@web.de>:\n>> Am 02.07.21 um 20:15 schrieb Junio C Hamano:\n>>> \"Ulrich Windl\" writes:\n>>>\n>>>> I was wondering whether git fsck should be able to cleanup\n>>>> orphaned branches (\"HEAD points to an unborn branch\") as described\n>>>> in https://stackoverflow.com/q/68226081/6607497 It seems I can fix\n>>>> it be editing files in the repository, but I feed that's not the\n>>>> way it should be.\n>>>\n>>> HEAD pointing at an unborn branch is not even a corruption, isn't\n>>> it?\n>>>\n>>> $ rm -rf trash && git init trash\n>>>\n>>> would point HEAD at an unborn one, ready to be used.\n>>\n>> True, but the scenario described on StackOverflow is a bit different.\n>> Commits were filtered out, and branches still pointing to them cannot\n>> be deleted with \"git branch -d\" or \"git branch -D\". Git fsck only\n>> reports them.\n>>\n>> You *can* overwrite them using \"git branch --force foo\" and then\n>> \"git branch -d foo\" works.\n>\n> Would it be OK to force the branch to any commit (e.g.: \"master\"), relying on\n> the fact that any reference (read: \"master\") to that commit will prevent actual\n> removal of the commit?\n\nYes, any valid commit would do. This turns dangling branches into\nnormal delete-able ones. Other branches are unaffected.\n\nRené\n"},{"id":"429258","messageId":"xmqq8s2kmtco.fsf@gitster.g","threadId":"56040","inReplyTo":"52847a99-db7c-9634-b3b1-fd9b1342bc32@web.de","subject":"Re: bug in \"git fsck\"?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-05T19:52:07Z","receivedAt":"2021-07-05T19:52:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe writes:\n\n> True, but the scenario described on StackOverflow is a bit different.\n> Commits were filtered out, and branches still pointing to them cannot\n> be deleted with \"git branch -d\" or \"git branch -D\". Git fsck only\n> reports them.\n\nI have a feeling that the \"filtering out\" process shouldn't leave\nthese stale branches hanging around in the first place (in other\nwords, it's the job of such a tool that deliberately \"corrupts\" the\nrepository to remove these branches, so that the user won't have to).\n\nBut I agree that it should be easy to recover from such a deliberate\nrepository corruption.\n"},{"id":"429277","messageId":"60E40275020000A1000422F7@gwsmtp.uni-regensburg.de","threadId":"56040","inReplyTo":"77655a4e-8c39-5ccc-71af-d2d8684bf208@web.de","subject":"Re: Antw: [EXT] Re: bug in \"git fsck\"?","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2021-07-06T07:12:53Z","receivedAt":"2021-07-06T07:13:00Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":">>> René Scharfe schrieb am 05.07.2021 um 16:44 in Nachricht\n<77655a4e-8c39-5ccc-71af-d2d8684bf208@web.de>:\n> Am 05.07.21 um 09:42 schrieb Ulrich Windl:\n>>>>> René Scharfe schrieb am 03.07.2021 um 22:03 in Nachricht\n>> <52847a99-db7c-9634-b3b1-fd9b1342bc32@web.de>:\n>>> Am 02.07.21 um 20:15 schrieb Junio C Hamano:\n>>>> \"Ulrich Windl\" writes:\n>>>>\n>>>>> I was wondering whether git fsck should be able to cleanup\n>>>>> orphaned branches (\"HEAD points to an unborn branch\") as described\n>>>>> in https://stackoverflow.com/q/68226081/6607497 It seems I can fix\n>>>>> it be editing files in the repository, but I feed that's not the\n>>>>> way it should be.\n>>>>\n>>>> HEAD pointing at an unborn branch is not even a corruption, isn't\n>>>> it?\n>>>>\n>>>> $ rm -rf trash && git init trash\n>>>>\n>>>> would point HEAD at an unborn one, ready to be used.\n>>>\n>>> True, but the scenario described on StackOverflow is a bit different.\n>>> Commits were filtered out, and branches still pointing to them cannot\n>>> be deleted with \"git branch -d\" or \"git branch -D\". Git fsck only\n>>> reports them.\n>>>\n>>> You *can* overwrite them using \"git branch --force foo\" and then\n>>> \"git branch -d foo\" works.\n>>\n>> Would it be OK to force the branch to any commit (e.g.: \"master\"), relying\n\n> on\n>> the fact that any reference (read: \"master\") to that commit will prevent \n> actual\n>> removal of the commit?\n> \n> Yes, any valid commit would do. This turns dangling branches into\n> normal delete-able ones. Other branches are unaffected.\n\nOK, but either it does not work, or I did not understand what to do:\n\n> git branch --force bitmap-generic\nfatal: Not a valid object name: 'bitmap-generic'.\n> git fsck\nChecking object directories: 100% (256/256), done.\nChecking objects: 100% (173/173), done.\nnotice: HEAD points to an unborn branch (bitmap-generic)\ndangling blob 0458be7cf03f35be365c819afe0104ff3c178ca0\ndangling blob 3000d29f0a652f3f7ed25572cac9969b90adeca5\ndangling commit 90e8531086d3efaeefdf6c8d39b6782e49dd2a0d\ndangling commit b598195f859106662bde746f391a7df9162231e9\ndangling tree fb4866ab5cc2f0c34a63334b90550ef7199a2098\n...\n\nRegards,\nUlrich\n\n\n> \n> René\n\n\n\n"},{"id":"429286","messageId":"fcfd0401-df5b-15ec-29c4-74d2903274cd@web.de","threadId":"56040","inReplyTo":"60E40275020000A1000422F7@gwsmtp.uni-regensburg.de","subject":"Re: Antw: [EXT] Re: bug in \"git fsck\"?","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2021-07-06T14:25:10Z","receivedAt":"2021-07-06T14:37:48Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 06.07.21 um 09:12 schrieb Ulrich Windl:\n>>>> René Scharfe schrieb am 05.07.2021 um 16:44 in Nachricht\n> <77655a4e-8c39-5ccc-71af-d2d8684bf208@web.de>:\n>> Am 05.07.21 um 09:42 schrieb Ulrich Windl:\n>>>> You *can* overwrite them using \"git branch --force foo\" and then\n>>>> \"git branch -d foo\" works.\n>>>\n>>> Would it be OK to force the branch to any commit (e.g.: \"master\"), relying\n>\n>> on\n>>> the fact that any reference (read: \"master\") to that commit will prevent\n>> actual\n>>> removal of the commit?\n>>\n>> Yes, any valid commit would do. This turns dangling branches into\n>> normal delete-able ones. Other branches are unaffected.\n>\n> OK, but either it does not work, or I did not understand what to do:\n>\n>> git branch --force bitmap-generic\n> fatal: Not a valid object name: 'bitmap-generic'.\n>> git fsck\n> Checking object directories: 100% (256/256), done.\n> Checking objects: 100% (173/173), done.\n> notice: HEAD points to an unborn branch (bitmap-generic)\n> dangling blob 0458be7cf03f35be365c819afe0104ff3c178ca0\n> dangling blob 3000d29f0a652f3f7ed25572cac9969b90adeca5\n> dangling commit 90e8531086d3efaeefdf6c8d39b6782e49dd2a0d\n> dangling commit b598195f859106662bde746f391a7df9162231e9\n> dangling tree fb4866ab5cc2f0c34a63334b90550ef7199a2098\n> ...\n\nFirst: Please make backups.\n\nHere's what works for me. First reproducing the error:\n\n $ echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >.git/refs/heads/broken\n $ git branch --delete --force broken\n error: Couldn't look up commit object for 'refs/heads/broken'\n\nNow I have a broken branch that I cannot delete. We should be on the\nsame page now.\n\n $ git branch\n broken\n * master\n\nSo I'm on master, a valid branch.\n\n $ git branch --force broken\n\nNow the broken branch is overwritten and points to the same commit as\nmaster.\n\n $ git branch --delete broken\n Deleted branch broken (was 83d267b).\n\nAnd now it's gone.\n\nRené\n"},{"id":"429475","messageId":"60E6B541020000A1000423C8@gwsmtp.uni-regensburg.de","threadId":"56040","inReplyTo":"fcfd0401-df5b-15ec-29c4-74d2903274cd@web.de","subject":"Re: Antw: [EXT] Re: bug in \"git fsck\"?","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2021-07-08T08:20:17Z","receivedAt":"2021-07-08T08:20:25Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":">>> René Scharfe schrieb am 06.07.2021 um 16:25 in Nachricht\n:\n> Am 06.07.21 um 09:12 schrieb Ulrich Windl:\n>>>>> René Scharfe schrieb am 05.07.2021 um 16:44 in Nachricht\n>> <77655a4e-8c39-5ccc-71af-d2d8684bf208@web.de>:\n>>> Am 05.07.21 um 09:42 schrieb Ulrich Windl:\n>>>>> You *can* overwrite them using \"git branch --force foo\" and then\n>>>>> \"git branch -d foo\" works.\n>>>>\n>>>> Would it be OK to force the branch to any commit (e.g.: \"master\"),\nrelying\n>>\n>>> on\n>>>> the fact that any reference (read: \"master\") to that commit will prevent\n>>> actual\n>>>> removal of the commit?\n>>>\n>>> Yes, any valid commit would do. This turns dangling branches into\n>>> normal delete-able ones. Other branches are unaffected.\n>>\n>> OK, but either it does not work, or I did not understand what to do:\n>>\n>>> git branch --force bitmap-generic\n>> fatal: Not a valid object name: 'bitmap-generic'.\n>>> git fsck\n>> Checking object directories: 100% (256/256), done.\n>> Checking objects: 100% (173/173), done.\n>> notice: HEAD points to an unborn branch (bitmap-generic)\n>> dangling blob 0458be7cf03f35be365c819afe0104ff3c178ca0\n>> dangling blob 3000d29f0a652f3f7ed25572cac9969b90adeca5\n>> dangling commit 90e8531086d3efaeefdf6c8d39b6782e49dd2a0d\n>> dangling commit b598195f859106662bde746f391a7df9162231e9\n>> dangling tree fb4866ab5cc2f0c34a63334b90550ef7199a2098\n>> ...\n> \n> First: Please make backups.\n> \n> Here's what works for me. First reproducing the error:\n> \n> $ echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >.git/refs/heads/broken\n\nHi!\n\nThanks for the hints. But first the problem is in the repository, not in the\nworkspace, so I don't have a \".git/refs/\", but \"refs/\".\nThe other thing is that the only \"refs\" that is there is \"master\"; the one\nwith the problem isn't there.\n\nSo I tried:\n% echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >refs/heads/bitmap-generic\nThen \"git branch\" indicated that \"bitmap-generic\" would be the current\nbranch:\n% cat HEAD\nref: refs/heads/bitmap-generic\n\nNext I brute-force edited HEAD, repacing bitmap-generic with master.\n\nStill, that would not work:\n% git branch --delete --force bitmap-generic\nerror: Couldn't look up commit object for 'refs/heads/bitmap-generic'\n\nBut the next command worked:\n% git branch --force bitmap-generic\n\nFinally, this also worked:\n% git branch --delete bitmap-generic\nDeleted branch bitmap-generic (was 03aa7ca).\n\nMost importantly \"git fsck\" did no longer complain.\n\nThanks for the help! Do you want to provide an answer to stackexchange, or may\nI use your procedure to write an answer?\n\nRegards,\nUlrich\n\n> $ git branch --delete --force broken\n> error: Couldn't look up commit object for 'refs/heads/broken'\n> \n> Now I have a broken branch that I cannot delete. We should be on the\n> same page now.\n> \n> $ git branch\n> broken\n> * master\n> \n> So I'm on master, a valid branch.\n> \n> $ git branch --force broken\n> \n> Now the broken branch is overwritten and points to the same commit as\n> master.\n> \n> $ git branch --delete broken\n> Deleted branch broken (was 83d267b).\n> \n> And now it's gone.\n> \n> René\n\n\n\n"},{"id":"429499","messageId":"f460e7e0-113e-f19f-fbaa-a22f567105dd@web.de","threadId":"56040","inReplyTo":"60E6B541020000A1000423C8@gwsmtp.uni-regensburg.de","subject":"Re: Antw: [EXT] Re: bug in \"git fsck\"?","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2021-07-08T16:36:37Z","receivedAt":"2021-07-08T16:36:40Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 08.07.21 um 10:20 schrieb Ulrich Windl:\n>>>> René Scharfe schrieb am 06.07.2021 um 16:25 in Nachricht\n> :\n>> Am 06.07.21 um 09:12 schrieb Ulrich Windl:\n>>>>>> René Scharfe schrieb am 05.07.2021 um 16:44 in Nachricht\n>>> <77655a4e-8c39-5ccc-71af-d2d8684bf208@web.de>:\n>>>> Am 05.07.21 um 09:42 schrieb Ulrich Windl:\n>>>>>> You *can* overwrite them using \"git branch --force foo\" and then\n>>>>>> \"git branch -d foo\" works.\n>>>>>\n>>>>> Would it be OK to force the branch to any commit (e.g.: \"master\"),\n> relying\n>>>\n>>>> on\n>>>>> the fact that any reference (read: \"master\") to that commit will prevent\n>>>> actual\n>>>>> removal of the commit?\n>>>>\n>>>> Yes, any valid commit would do. This turns dangling branches into\n>>>> normal delete-able ones. Other branches are unaffected.\n>>>\n>>> OK, but either it does not work, or I did not understand what to do:\n>>>\n>>>> git branch --force bitmap-generic\n>>> fatal: Not a valid object name: 'bitmap-generic'.\n>>>> git fsck\n>>> Checking object directories: 100% (256/256), done.\n>>> Checking objects: 100% (173/173), done.\n>>> notice: HEAD points to an unborn branch (bitmap-generic)\n>>> dangling blob 0458be7cf03f35be365c819afe0104ff3c178ca0\n>>> dangling blob 3000d29f0a652f3f7ed25572cac9969b90adeca5\n>>> dangling commit 90e8531086d3efaeefdf6c8d39b6782e49dd2a0d\n>>> dangling commit b598195f859106662bde746f391a7df9162231e9\n>>> dangling tree fb4866ab5cc2f0c34a63334b90550ef7199a2098\n>>> ...\n>>\n>> First: Please make backups.\n>>\n>> Here's what works for me. First reproducing the error:\n>>\n>> $ echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >.git/refs/heads/broken\n>\n> Hi!\n>\n> Thanks for the hints. But first the problem is in the repository, not in the\n> workspace, so I don't have a \".git/refs/\", but \"refs/\".\n\nSo you have a bare repository (one without worktree, i.e. no checked out\nfiles)?\n\n> The other thing is that the only \"refs\" that is there is \"master\"; the one\n> with the problem isn't there.\n\nYou probably had your refs packed (in a file named \"packed-refs\").\n\n> So I tried:\n> % echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >refs/heads/bitmap-generic\n\nI used that command to generate a broken branch. You already had a\nbroken branch, so you didn't need to repeat that reproduction step.\n\n> Then \"git branch\" indicated that \"bitmap-generic\" would be the current\n> branch:\n> % cat HEAD\n> ref: refs/heads/bitmap-generic\n\nHEAD references the current branch. So the broken branch was the\ncurrent one for you? I somehow assumed that you'd be on a healthy\nbranch. And I'm not fully sure how to use branches in a bare\nrepository.\n\n> Next I brute-force edited HEAD, repacing bitmap-generic with master.\n\nOK, but at least this moved you to a healthy branch.\n\n> Still, that would not work:\n> % git branch --delete --force bitmap-generic\n> error: Couldn't look up commit object for 'refs/heads/bitmap-generic'\n\nExpected; you hadn't done anything to that branch, yet.\n\n> But the next command worked:\n> % git branch --force bitmap-generic\n\nThis made the broken branch point to the same commit as the current\nbranch, i.e. master.\n\n> Finally, this also worked:\n> % git branch --delete bitmap-generic\n> Deleted branch bitmap-generic (was 03aa7ca).\n\nRight; the previous command had unbroken the branch, so it had\nbecome deletable.\n\n> Most importantly \"git fsck\" did no longer complain.\n>\n> Thanks for the help! Do you want to provide an answer to stackexchange, or may\n> I use your procedure to write an answer?\n\nFeel free to use it. I don't even have an account there.\n\nRené\n"}]}