Re: Antw: [EXT] Re: bug in "git fsck"?
- From
René Scharfe <l.s.r@web.de>
- Date
- Jul 5, 2021, 14:44 UTC
- Message-ID
- <77655a4e-8c39-5ccc-71af-d2d8684bf208@web.de>
- In-Reply-To
- <60E2B7FB020000A1000422A0@gwsmtp.uni-regensburg.de>
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é