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

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