Re: [PATCH v2 3/4] ref: add symbolic ref content check for files backend

On Wed, Aug 28, 2024 at 08:41:08AM -0700, Junio C Hamano wrote:

Patrick Steinhardt [off-list ref] writes:

quoted

Also, I think we don't typically call the value of a symbolic ref
"pointee", but "target". Searching for "pointee" in our codebase only
gives a single hit, and that one is not related to symbolic refs.

Yesterday while I was studying for reviewing this series, I saw some
existing code that call them "referent".  There may also be "target".

Ah, true, I totally forgot about "referent". I guess we use both, but it
would of course be great if we only had a single term to refer them.
Referent seems to be used more widely, at least in the refs subsystem.

quoted

quoted

+	if (!newline_pos || *(newline_pos + 1)) {
+		ret = fsck_report_ref(o, report,
+				      FSCK_MSG_REF_MISSING_NEWLINE,
+				      "missing newline");
+	}

The second condition `*(newline_pos + 1)` checks whether there is any
data after the newline, doesn't it? That indicates a different kind of
error than "missing newline", namely that there is trailing garbage. I
guess we'd want to report a separate info-level message for this.

Also, shouldn't we use `strchr` instead of `strrchr()`? Otherwise, we're
only checking for trailing garbage after the _last_ newline, not after
the first one.

None of the above.  It should strbuf_rtrim() and if we removed
anything but just a single terminating LF, we are looking at
something we wouldn't ahve written.  The next check_refname_format()
call would then find "trailing garbage".

Fair.

 - "refs/heads/master \n " gets rtrimmed to "refs/heads/master",
   which is "valid but curious".

Okay. This _may_ be something to generate an info message for, mostly in
the same spirit as we want to do it for direct refs.

 - "refs/heads/main trash\n " becomes "refs/heads/main trash",
   which is outright bad.

Yeah, this one should be an error indeed.

Patrick