threads / bug / 56040

bug in "git fsck"?

Subject: bug in "git fsck"?

## tl;dr

13 messages between Jul 2, 2021 and Jul 8, 2021.

replies: 12people: 4as markdown or json

Ulrich Windl· Jul 2, 2021, 14:01 UTC · lore
Hi!

I 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 It seems I can fix it be editing files in the repository, but I feed that's not the way it should be.

Regards, Ulrich

Junio C Hamano· Jul 2, 2021, 18:15 UTC · re: Ulrich Windl · lore

Re: bug in "git fsck"?

"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> writes:
Show 5 quoted lines
> I 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 It seems I can fix
> it be editing files in the repository, but I feed that's not the
> way it should be.

HEAD pointing at an unborn branch is not even a corruption, isn't it?

   $ rm -rf trash && git init trash
would point HEAD at an unborn one, ready to be used.
René Scharfe· Jul 3, 2021, 20:03 UTC · re: Junio C Hamano · lore

Re: bug in "git fsck"?

Am 02.07.21 um 20:15 schrieb Junio C Hamano:
Show 14 quoted lines
> "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> writes:
>
>> I 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 It seems I can fix
>> it be editing files in the repository, but I feed that's not the
>> way it should be.
>
> HEAD pointing at an unborn branch is not even a corruption, isn't
> it?
>
>    $ rm -rf trash && git init trash
>
> would point HEAD at an unborn one, ready to be used.

True, but the scenario described on StackOverflow is a bit different. Commits were filtered out, and branches still pointing to them cannot be deleted with "git branch -d" or "git branch -D". Git fsck only reports them.

You *can* overwrite them using "git branch --force foo" and then "git branch -d foo" works.

I think it makes sense to let "git branch -D foo" work directly in such a case. That would be a user-visible change that may cause data loss, so we better be careful. I can't imagine a practical data-loss scenario, but that might be just me. Under which circumstances do we want to keep a branch that does not point to a commit?

Anyway, here's what the change would look like:
--- >8 ---
Subject: [PATCH] branch: allow deleting dangling branches with --force

git branch only allows deleting branches that point to valid commits. Skip that check if --force is given, as the caller is indicating with it that they know what they are doing and accept the consequences. This allows deleting dangling branches, which previously had to be reset to a valid start-point using --force first.

Signed-off-by: René Scharfe <l.s.r@web.de>
---
 Documentation/git-branch.txt | 3 ++-
 builtin/branch.c             | 2 +-
 t/t3200-branch.sh            | 7 +++++++
 3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 94dc9a54f2..5449767121 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -118,7 +118,8 @@ OPTIONS
 	Reset <branchname> to <startpoint>, even if <branchname> exists
 	already. Without `-f`, 'git branch' refuses to change an existing branch.
 	In combination with `-d` (or `--delete`), allow deleting the
-	branch irrespective of its merged status. In combination with
+	branch irrespective of its merged status, or whether it even
+	points to a valid commit. In combination with
 	`-m` (or `--move`), allow renaming the branch even if the new
 	branch name already exists, the same applies for `-c` (or `--copy`).

diff --git a/builtin/branch.c b/builtin/branch.c
index b23b1d1752..03c7b7253a 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -168,7 +168,7 @@ static int check_branch_commit(const char *branchname, const char *refname,
 			       int kinds, int force)
 {
 	struct commit *rev = lookup_commit_reference(the_repository, oid);
-	if (!rev) {
+	if (!force && !rev) {
 		error(_("Couldn't look up commit object for '%s'"), refname);
 		return -1;
 	}
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index cc4b10236e..ec61a10c29 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -1272,6 +1272,13 @@ test_expect_success 'attempt to delete a branch merged to its base' '
 	test_must_fail git branch -d my10
 '

+test_expect_success 'branch --delete --force removes dangling branch' '
+	test_when_finished "rm -f .git/refs/heads/dangling" &&
+	echo $ZERO_OID >.git/refs/heads/dangling &&
+	git branch --delete --force dangling &&
+	test_path_is_missing .git/refs/heads/dangling
+'
+
 test_expect_success 'use --edit-description' '
 	write_script editor <<-\EOF &&
 		echo "New contents" >"$1"
--
2.32.0
Ulrich Windl· Jul 5, 2021, 07:42 UTC · re: René Scharfe · lore

Antw: [EXT] Re: bug in "git fsck"?

>>> René Scharfe <l.s.r@web.de> schrieb am 03.07.2021 um 22:03 in Nachricht
<52847a99-db7c-9634-b3b1-fd9b1342bc32@web.de>:
Show 23 quoted lines
> Am 02.07.21 um 20:15 schrieb Junio C Hamano:
>> "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> writes:
>>
>>> I 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 It seems I can fix
>>> it be editing files in the repository, but I feed that's not the
>>> way it should be.
>>
>> HEAD pointing at an unborn branch is not even a corruption, isn't
>> it?
>>
>>    $ rm -rf trash && git init trash
>>
>> would point HEAD at an unborn one, ready to be used.
> 
> True, but the scenario described on StackOverflow is a bit different.
> Commits were filtered out, and branches still pointing to them cannot
> be deleted with "git branch -d" or "git branch -D".  Git fsck only
> reports them.
> 
> You *can* overwrite them using "git branch --force foo" and then
> "git branch -d foo" works.

Would it be OK to force the branch to any commit (e.g.: "master"), relying on the fact that any reference (read: "master") to that commit will prevent actual removal of the commit?

René Scharfe· Jul 5, 2021, 14:44 UTC · re: Ulrich Windl · lore

Re: Antw: [EXT] Re: bug in "git fsck"?

Am 05.07.21 um 09:42 schrieb Ulrich Windl:
Show 29 quoted lines
>>>> René Scharfe <l.s.r@web.de> schrieb am 03.07.2021 um 22:03 in Nachricht
> <52847a99-db7c-9634-b3b1-fd9b1342bc32@web.de>:
>> Am 02.07.21 um 20:15 schrieb Junio C Hamano:
>>> "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> writes:
>>>
>>>> I 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 It seems I can fix
>>>> it be editing files in the repository, but I feed that's not the
>>>> way it should be.
>>>
>>> HEAD pointing at an unborn branch is not even a corruption, isn't
>>> it?
>>>
>>>    $ rm -rf trash && git init trash
>>>
>>> would point HEAD at an unborn one, ready to be used.
>>
>> True, but the scenario described on StackOverflow is a bit different.
>> Commits were filtered out, and branches still pointing to them cannot
>> be deleted with "git branch -d" or "git branch -D".  Git fsck only
>> reports them.
>>
>> You *can* overwrite them using "git branch --force foo" and then
>> "git branch -d foo" works.
>
> Would it be OK to force the branch to any commit (e.g.: "master"), relying on
> the fact that any reference (read: "master") to that commit will prevent actual
> removal of the commit?

Yes, any valid commit would do. This turns dangling branches into normal delete-able ones. Other branches are unaffected.

René
Ulrich Windl· Jul 6, 2021, 07:12 UTC · re: René Scharfe · lore

Re: Antw: [EXT] Re: bug in "git fsck"?

>>> René Scharfe <l.s.r@web.de> schrieb am 05.07.2021 um 16:44 in Nachricht
<77655a4e-8c39-5ccc-71af-d2d8684bf208@web.de>:
Show 28 quoted lines
> Am 05.07.21 um 09:42 schrieb Ulrich Windl:
>>>>> René Scharfe <l.s.r@web.de> schrieb am 03.07.2021 um 22:03 in Nachricht
>> <52847a99-db7c-9634-b3b1-fd9b1342bc32@web.de>:
>>> Am 02.07.21 um 20:15 schrieb Junio C Hamano:
>>>> "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> writes:
>>>>
>>>>> I 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 It seems I can fix
>>>>> it be editing files in the repository, but I feed that's not the
>>>>> way it should be.
>>>>
>>>> HEAD pointing at an unborn branch is not even a corruption, isn't
>>>> it?
>>>>
>>>>    $ rm -rf trash && git init trash
>>>>
>>>> would point HEAD at an unborn one, ready to be used.
>>>
>>> True, but the scenario described on StackOverflow is a bit different.
>>> Commits were filtered out, and branches still pointing to them cannot
>>> be deleted with "git branch -d" or "git branch -D".  Git fsck only
>>> reports them.
>>>
>>> You *can* overwrite them using "git branch --force foo" and then
>>> "git branch -d foo" works.
>>
>> Would it be OK to force the branch to any commit (e.g.: "master"), relying
Show 7 quoted lines
> on
>> the fact that any reference (read: "master") to that commit will prevent 
> actual
>> removal of the commit?
> 
> Yes, any valid commit would do.  This turns dangling branches into
> normal delete-able ones.  Other branches are unaffected.
OK, but either it does not work, or I did not understand what to do:
> git branch --force bitmap-generic
fatal: Not a valid object name: 'bitmap-generic'.
> git fsck

Checking object directories: 100% (256/256), done. Checking objects: 100% (173/173), done. notice: HEAD points to an unborn branch (bitmap-generic) dangling blob 0458be7cf03f35be365c819afe0104ff3c178ca0 dangling blob 3000d29f0a652f3f7ed25572cac9969b90adeca5 dangling commit 90e8531086d3efaeefdf6c8d39b6782e49dd2a0d dangling commit b598195f859106662bde746f391a7df9162231e9 dangling tree fb4866ab5cc2f0c34a63334b90550ef7199a2098 ...

Regards, Ulrich

> 
> René
René Scharfe· Jul 6, 2021, 14:25 UTC · re: Ulrich Windl · lore

Re: Antw: [EXT] Re: bug in "git fsck"?

Am 06.07.21 um 09:12 schrieb Ulrich Windl:
Show 30 quoted lines
>>>> René Scharfe <l.s.r@web.de> schrieb am 05.07.2021 um 16:44 in Nachricht
> <77655a4e-8c39-5ccc-71af-d2d8684bf208@web.de>:
>> Am 05.07.21 um 09:42 schrieb Ulrich Windl:
>>>> You *can* overwrite them using "git branch --force foo" and then
>>>> "git branch -d foo" works.
>>>
>>> Would it be OK to force the branch to any commit (e.g.: "master"), relying
>
>> on
>>> the fact that any reference (read: "master") to that commit will prevent
>> actual
>>> removal of the commit?
>>
>> Yes, any valid commit would do.  This turns dangling branches into
>> normal delete-able ones.  Other branches are unaffected.
>
> OK, but either it does not work, or I did not understand what to do:
>
>> git branch --force bitmap-generic
> fatal: Not a valid object name: 'bitmap-generic'.
>> git fsck
> Checking object directories: 100% (256/256), done.
> Checking objects: 100% (173/173), done.
> notice: HEAD points to an unborn branch (bitmap-generic)
> dangling blob 0458be7cf03f35be365c819afe0104ff3c178ca0
> dangling blob 3000d29f0a652f3f7ed25572cac9969b90adeca5
> dangling commit 90e8531086d3efaeefdf6c8d39b6782e49dd2a0d
> dangling commit b598195f859106662bde746f391a7df9162231e9
> dangling tree fb4866ab5cc2f0c34a63334b90550ef7199a2098
> ...
First: Please make backups.
Here's what works for me.  First reproducing the error:
   $ echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >.git/refs/heads/broken
   $ git branch --delete --force broken
   error: Couldn't look up commit object for 'refs/heads/broken'

Now I have a broken branch that I cannot delete. We should be on the same page now.

   $ git branch
     broken
   * master
So I'm on master, a valid branch.
   $ git branch --force broken

Now the broken branch is overwritten and points to the same commit as master.

   $ git branch --delete broken
   Deleted branch broken (was 83d267b).
And now it's gone.
René
Ulrich Windl· Jul 8, 2021, 08:20 UTC · re: René Scharfe · lore

Re: Antw: [EXT] Re: bug in "git fsck"?

>>> René Scharfe <l.s.r@web.de> schrieb am 06.07.2021 um 16:25 in Nachricht
<fcfd0401-df5b-15ec-29c4-74d2903274cd@web.de>:
Show 8 quoted lines
> Am 06.07.21 um 09:12 schrieb Ulrich Windl:
>>>>> René Scharfe <l.s.r@web.de> schrieb am 05.07.2021 um 16:44 in Nachricht
>> <77655a4e-8c39-5ccc-71af-d2d8684bf208@web.de>:
>>> Am 05.07.21 um 09:42 schrieb Ulrich Windl:
>>>>> You *can* overwrite them using "git branch --force foo" and then
>>>>> "git branch -d foo" works.
>>>>
>>>> Would it be OK to force the branch to any commit (e.g.: "master"),
relying
Show 29 quoted lines
>>
>>> on
>>>> the fact that any reference (read: "master") to that commit will prevent
>>> actual
>>>> removal of the commit?
>>>
>>> Yes, any valid commit would do.  This turns dangling branches into
>>> normal delete-able ones.  Other branches are unaffected.
>>
>> OK, but either it does not work, or I did not understand what to do:
>>
>>> git branch --force bitmap-generic
>> fatal: Not a valid object name: 'bitmap-generic'.
>>> git fsck
>> Checking object directories: 100% (256/256), done.
>> Checking objects: 100% (173/173), done.
>> notice: HEAD points to an unborn branch (bitmap-generic)
>> dangling blob 0458be7cf03f35be365c819afe0104ff3c178ca0
>> dangling blob 3000d29f0a652f3f7ed25572cac9969b90adeca5
>> dangling commit 90e8531086d3efaeefdf6c8d39b6782e49dd2a0d
>> dangling commit b598195f859106662bde746f391a7df9162231e9
>> dangling tree fb4866ab5cc2f0c34a63334b90550ef7199a2098
>> ...
> 
> First: Please make backups.
> 
> Here's what works for me.  First reproducing the error:
> 
>    $ echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >.git/refs/heads/broken
Hi!

Thanks for the hints. But first the problem is in the repository, not in the workspace, so I don't have a ".git/refs/", but "refs/". The other thing is that the only "refs" that is there is "master"; the one with the problem isn't there.

So I tried: % echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >refs/heads/bitmap-generic Then "git branch" indicated that "bitmap-generic" would be the current branch: % cat HEAD ref: refs/heads/bitmap-generic

Next I brute-force edited HEAD, repacing bitmap-generic with master.

Still, that would not work: % git branch --delete --force bitmap-generic error: Couldn't look up commit object for 'refs/heads/bitmap-generic'

But the next command worked: % git branch --force bitmap-generic

Finally, this also worked: % git branch --delete bitmap-generic Deleted branch bitmap-generic (was 03aa7ca).

Most importantly "git fsck" did no longer complain.

Thanks for the help! Do you want to provide an answer to stackexchange, or may I use your procedure to write an answer?

Regards, Ulrich

Show 23 quoted lines
>    $ git branch --delete --force broken
>    error: Couldn't look up commit object for 'refs/heads/broken'
> 
> Now I have a broken branch that I cannot delete.  We should be on the
> same page now.
> 
>    $ git branch
>      broken
>    * master
> 
> So I'm on master, a valid branch.
> 
>    $ git branch --force broken
> 
> Now the broken branch is overwritten and points to the same commit as
> master.
> 
>    $ git branch --delete broken
>    Deleted branch broken (was 83d267b).
> 
> And now it's gone.
> 
> René
René Scharfe· Jul 8, 2021, 16:36 UTC · re: Ulrich Windl · lore

Re: Antw: [EXT] Re: bug in "git fsck"?

Am 08.07.21 um 10:20 schrieb Ulrich Windl:
Show 45 quoted lines
>>>> René Scharfe <l.s.r@web.de> schrieb am 06.07.2021 um 16:25 in Nachricht
> <fcfd0401-df5b-15ec-29c4-74d2903274cd@web.de>:
>> Am 06.07.21 um 09:12 schrieb Ulrich Windl:
>>>>>> René Scharfe <l.s.r@web.de> schrieb am 05.07.2021 um 16:44 in Nachricht
>>> <77655a4e-8c39-5ccc-71af-d2d8684bf208@web.de>:
>>>> Am 05.07.21 um 09:42 schrieb Ulrich Windl:
>>>>>> You *can* overwrite them using "git branch --force foo" and then
>>>>>> "git branch -d foo" works.
>>>>>
>>>>> Would it be OK to force the branch to any commit (e.g.: "master"),
> relying
>>>
>>>> on
>>>>> the fact that any reference (read: "master") to that commit will prevent
>>>> actual
>>>>> removal of the commit?
>>>>
>>>> Yes, any valid commit would do.  This turns dangling branches into
>>>> normal delete-able ones.  Other branches are unaffected.
>>>
>>> OK, but either it does not work, or I did not understand what to do:
>>>
>>>> git branch --force bitmap-generic
>>> fatal: Not a valid object name: 'bitmap-generic'.
>>>> git fsck
>>> Checking object directories: 100% (256/256), done.
>>> Checking objects: 100% (173/173), done.
>>> notice: HEAD points to an unborn branch (bitmap-generic)
>>> dangling blob 0458be7cf03f35be365c819afe0104ff3c178ca0
>>> dangling blob 3000d29f0a652f3f7ed25572cac9969b90adeca5
>>> dangling commit 90e8531086d3efaeefdf6c8d39b6782e49dd2a0d
>>> dangling commit b598195f859106662bde746f391a7df9162231e9
>>> dangling tree fb4866ab5cc2f0c34a63334b90550ef7199a2098
>>> ...
>>
>> First: Please make backups.
>>
>> Here's what works for me.  First reproducing the error:
>>
>>    $ echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >.git/refs/heads/broken
>
> Hi!
>
> Thanks for the hints. But first the problem is in the repository, not in the
> workspace, so I don't have a ".git/refs/", but "refs/".

So you have a bare repository (one without worktree, i.e. no checked out files)?

> The other thing is that the only "refs" that is there is "master"; the one
> with the problem isn't there.
You probably had your refs packed (in a file named "packed-refs").
> So I tried:
> % echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >refs/heads/bitmap-generic

I used that command to generate a broken branch. You already had a broken branch, so you didn't need to repeat that reproduction step.

> Then "git branch" indicated that "bitmap-generic" would be the current
> branch:
> % cat HEAD
> ref: refs/heads/bitmap-generic

HEAD references the current branch. So the broken branch was the current one for you? I somehow assumed that you'd be on a healthy branch. And I'm not fully sure how to use branches in a bare repository.

> Next I brute-force edited HEAD, repacing bitmap-generic with master.
OK, but at least this moved you to a healthy branch.
> Still, that would not work:
> % git branch --delete --force bitmap-generic
> error: Couldn't look up commit object for 'refs/heads/bitmap-generic'
Expected; you hadn't done anything to that branch, yet.
> But the next command worked:
> % git branch --force bitmap-generic

This made the broken branch point to the same commit as the current branch, i.e. master.

> Finally, this also worked:
> % git branch --delete bitmap-generic
> Deleted branch bitmap-generic (was 03aa7ca).

Right; the previous command had unbroken the branch, so it had become deletable.

> Most importantly "git fsck" did no longer complain.
>
> Thanks for the help! Do you want to provide an answer to stackexchange, or may
> I use your procedure to write an answer?
Feel free to use it.  I don't even have an account there.
René
Junio C Hamano· Jul 5, 2021, 19:52 UTC · re: René Scharfe · lore

Re: bug in "git fsck"?

René Scharfe <l.s.r@web.de> writes:
> True, but the scenario described on StackOverflow is a bit different.
> Commits were filtered out, and branches still pointing to them cannot
> be deleted with "git branch -d" or "git branch -D".  Git fsck only
> reports them.

I have a feeling that the "filtering out" process shouldn't leave these stale branches hanging around in the first place (in other words, it's the job of such a tool that deliberately "corrupts" the repository to remove these branches, so that the user won't have to).

But I agree that it should be easy to recover from such a deliberate repository corruption.

Ulrich Windl· Jul 5, 2021, 07:10 UTC · re: Junio C Hamano · lore

Antw: [EXT] Re: bug in "git fsck"?

>>> Junio C Hamano <gitster@pobox.com> schrieb am 02.07.2021 um 20:15 in

Nachricht <xmqqczs0popg.fsf@gitster.g>:

Show 14 quoted lines
> "Ulrich Windl" <Ulrich.Windl@rz.uni‑regensburg.de> writes:
> 
>> I 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 It seems I can fix
>> it be editing files in the repository, but I feed that's not the
>> way it should be.
> 
> HEAD pointing at an unborn branch is not even a corruption, isn't
> it?
> 
>    $ rm ‑rf trash && git init trash
> 
> would point HEAD at an unborn one, ready to be used.

OK, so maybe I was just confused by "fsck". At it seems after committing, fsck no longer complains. As "EXTRACTED DIAGNOSTICS" In man git-fsck (Git 2.26.2) does not mention "unborn" (and as it's not a common IT phrase), one could probably explain what it means.

Regards, Ulrich

Ævar Arnfjörð Bjarmason· Jul 5, 2021, 07:26 UTC · re: Ulrich Windl · lore

Re: Antw: [EXT] Re: bug in "git fsck"?

On Mon, Jul 05 2021, Ulrich Windl wrote:
Show 24 quoted lines
>>>> Junio C Hamano <gitster@pobox.com> schrieb am 02.07.2021 um 20:15 in
> Nachricht
> <xmqqczs0popg.fsf@gitster.g>:
>> "Ulrich Windl" <Ulrich.Windl@rz.uni‑regensburg.de> writes:
>> 
>>> I 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 It seems I can fix
>>> it be editing files in the repository, but I feed that's not the
>>> way it should be.
>> 
>> HEAD pointing at an unborn branch is not even a corruption, isn't
>> it?
>> 
>>    $ rm ‑rf trash && git init trash
>> 
>> would point HEAD at an unborn one, ready to be used.
>
>
> OK, so maybe I was just confused by "fsck". At it seems after committing, fsck
> no longer complains.
> As "EXTRACTED DIAGNOSTICS" In man git-fsck (Git 2.26.2) does not mention
> "unborn" (and as it's not a common IT phrase), one could probably explain what
> it means.

FWIW you're completely right about the unstated point that fsck's error messages/reporting is pretty bad. I've been trying to fix some of it up recently (including one hopefully soon-to-land series).

It has a bunch of output that's overly verbose, and other complaints where it's not clear if they're actionable or not (e.g. what you mentioned), or whether it's even a problem.

If I create an ext4 filesystem and run fsck on it it's not going to complain that there's no files yet, so it's a bit silly that fsck complains about a freshly git-init'd repo.

Ulrich Windl· Jul 5, 2021, 07:20 UTC · re: Junio C Hamano · lore

Antw: [EXT] Re: bug in "git fsck"?

>>> Ulrich Windl schrieb am 05.07.2021 um 09:10 in Nachricht <60E2B04B.461 :

161 : 60728>:

>>>> Junio C Hamano <gitster@pobox.com> schrieb am 02.07.2021 um 20:15 in
Nachricht
Show 19 quoted lines
> <xmqqczs0popg.fsf@gitster.g>:
> > "Ulrich Windl" <Ulrich.Windl@rz.uni‑regensburg.de> writes:
> > 
> >> I 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 It seems I can fix
> >> it be editing files in the repository, but I feed that's not the
> >> way it should be.
> > 
> > HEAD pointing at an unborn branch is not even a corruption, isn't
> > it?
> > 
> >    $ rm ‑rf trash && git init trash
> > 
> > would point HEAD at an unborn one, ready to be used.
> 
> 
> OK, so maybe I was just confused by "fsck". At it seems after committing, 
> fsck no longer complains.

Sorry, I didn't think (still pre-coffeine time): The problem is gone in the workspace so far, not in the repository, and I think the problem never was present in the workspace. Also "git branch" dispalys three branches in addition to "master", while the "branches" directory of the repository is empty. So when I try to delete a branch displayed by "git branch", I get: fatal: Couldn't look up commit object for HEAD

It seems the delete command reads those refs from HEAD: ref: refs/heads/name_of_branch_to_be_deleted

but in refs/heads/ that name does not exist

Last command before error message is: lstat("./objects/00/00000000000000000000000000000000000000", 0x7fff76d9a180) = -1 ENOENT (No such file or directory) write(2, "fatal: Couldn't look up commit o"..., 47fatal: Couldn't look up commit object for HEAD ) = 47

Show 10 quoted lines
> As "EXTRACTED DIAGNOSTICS" In man git-fsck (Git 2.26.2) does not mention 
> "unborn" (and as it's not a common IT phrase), one could probably explain 
> what it means.
> 
> Regards,
> Ulrich
> 
> 
> 
>

← back to recent threads