bug in "git fsck"?

bug in "git fsck"?

[Ulrich Windl]

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

Re: bug in "git fsck"?

[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.

Re: bug in "git fsck"?

[René Scharfe]

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.

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

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

[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 on
the fact that any reference (read: "master") to that commit will prevent actual
removal of the commit?

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

[René Scharfe]

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 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é

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

[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:
>>>>> 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.

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é

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

[René Scharfe]

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
   $ 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é

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

[Ulrich Windl]

>>> 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/".
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

>    $ 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é

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

[René Scharfe]

Am 08.07.21 um 10:20 schrieb Ulrich Windl:
>>>> 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é

Re: bug in "git fsck"?

[Junio C Hamano]

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.

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

[Ulrich Windl]

>>> 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.

Regards,
Ulrich

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

[Ævar Arnfjörð Bjarmason]

On Mon, Jul 05 2021, Ulrich Windl wrote:

>>>> 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.

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

[Ulrich Windl]

>>> 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
> <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


> 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
> 
> 
> 
>