shejialuo <shejialuo@xxxxxxxxx> writes: > On Fri, Jan 31, 2025 at 08:20:36AM -0800, Junio C Hamano wrote: >> shejialuo <shejialuo@xxxxxxxxx> writes: >> >> > >> > As I have said in the previous comment, we cannot detect the error if >> > "HEAD" itself is corrupted. However, we will check the referent in the >> > later. So, we don't need to do this. >> >> I still think you absolutely need to diagnose and tell the user >> about the broken HEAD. With your "don't check HEAD because a >> repository with a broken HEAD is not a repository", a check run in >> such a place may find everything else in the repository perfectly >> fine, but because the user wanted "git refs verify" to tell them >> about breakages, you would want to somehow tell them about it. >> Either it is missing, malformed, whatever. > > Yes, that's absolutely correct. However, I don't want to do this in > this series. Actually, there is no check for root ref. I will add checks > for root refs later. Another thing I just thought of is that what is your plans for repository discovery when HEAD is iffy. In the working tree of our project, you go to a subdirectory, say "t/", and then corrupt the HEAD, would "git refs verify" still recognise that ../.git/ is the "repository" the user is interested in, but it has a broken HEAD? setup.c:is_git_directory() would say "no", so I am not sure the discovery would work without changing that, and I am not sure if it is worth doing (i.e. when the user knows the repository's HEAD is broken, it is OK to disable discovery and force them to say GIT_DIR=/this/directory).
