Antw: [EXT] Re: bug in "git fsck"?
- From
- Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
- Date
- Jul 5, 2021, 07:42 UTC
- Message-ID
- <60E2B7FB020000A1000422A0@gwsmtp.uni-regensburg.de>
- In-Reply-To
- <52847a99-db7c-9634-b3b1-fd9b1342bc32@web.de>
>>> 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?