On Mon, Feb 03, 2025 at 12:15:39PM -0800, Junio C Hamano wrote: > 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). I have to say I am not so familiar with the "setup.c" code. Thanks for the direction here, I will dive into to figure out a solution. Thanks, Jialuo
