shejialuo [off-list ref] writes:

Hi All:

We have already set up the infrastructure of the ref consistency.
However, we have only add ref name check when establishing the
infrastructure in below:

  https://lore.kernel.org/git/ZrSqMmD-quQ18a9F@ArchLinux.localdomain/ (local)

Actually, we already have a patch here which has already implemented the
ref content consistency check. But during the review process, we have
encountered some problems. The intention of this RFC is to make sure
what content we should check and also to what extend.

I conclude the following info:

1. For the regular ref which has a trailing garbage, we should warn the
user. This is the most simplest situation, we could reply on
"parse_loose_ref_content" to do this.
2. For the symref, we could also rely on "parse_loose_ref_content" to
get the "pointee", and check the location of the "pointee", check the
name of the "pointee" and the file type of the "pointee".
3. FOr the symbolic ref, we could follow the idea of 2.

Just to understand clearly, when you're talking about 'symbolic ref' you
are referring to symbolic links?

I ask because, as per our documentation in
'Documentation/git-symbolic-ref.txt':

  In the past, `.git/HEAD` was a symbolic link pointing at
  `refs/heads/master`.  When we wanted to switch to another branch, we
  did `ln -sf refs/heads/newbranch .git/HEAD`, and when we wanted to
  find out which branch we are on, we did `readlink .git/HEAD`. But
  symbolic links are not entirely portable, so they are now deprecated
  and symbolic refs (as described above) are used by default.

But Patrick gives a question here:

quoted

In case the ref ends with a newline, should we check that the next
character is `\0`? Otherwise, it may contain multiple lines, which is
not allowed for a normal ref.

Also, shouldn't the ref always end with a newline?

For symref, I guess we have no spec here. From my experiments, a symref
could have a newline or no newline, even multiple newlines. And also
symref could have multiple spaces. But the following is a bad symref

  ref: refs/heads/main garbage

I think we should fully discuss what we should check here. Thus I will
implement the code.

Agreed, in refs/files-backend.c:create_symref_lock, we write symrefs as
"ref: %s\n" so it makes sense to validate that there is nothing extra.