shejialuo <shejialuo@xxxxxxxxx> writes:
> +`refMissingNewline`::
> + (INFO) A ref does not end with newline. This will be
> + considered an error in the future.
It is ONLY files backend's loose-ref representation to store the
object name that is the value of the ref as hexadecimal text
terminated with a newline. With packed backend, even if the file
ends with an incomplete line, it would be confusing to say that such
lack of terminating LF is associated with a particular ref. With
reftable backend, the object name may not even be hexadecimal but
binary without any terminating LF.
At least you should say "A loose ref file that does not end with...",
because a ref NEVER ends or contains newline, and what you are
expecting to be terminated with LF is not even a ref, but the value
of it.
Also, isn't it too strong to say "will be" without giving any
further information, like:
As valid implementations of Git never created such a loose ref
file, it may become an error in the future. Report to the
git@xxxxxxxxxxxxxxx mailing list if you see this error, as we
need to know what tools created such a file.
or something?
The same comment applies to the next entry.
> @@ -619,6 +619,10 @@ int parse_loose_ref_contents(const struct git_hash_algo *algop,
> *failure_errno = EINVAL;
> return -1;
> }
> +
> + if (trailing)
> + *trailing = p;
> +
> return 0;
In the pre-context of this hunk, if parse_oid_hex_algoph() failed to
recognise the initial segment of buf as a valid hexadecimal object
name, it would have already returned, so we know 'p' is always valid
here. It is the byte that comes immediately after the hexadecimal
object name.
OK.
> if (parse_loose_ref_contents(ref_store->repo->hash_algo,
> ref_content.buf, &oid, &referent,
> - &type, &failure_errno)) {
> + &type, &trailing, &failure_errno)) {
> ret = fsck_report_ref(o, &report,
> FSCK_MSG_BAD_REF_CONTENT,
> "invalid ref content");
> goto cleanup;
> }
>
> + if (!(type & REF_ISSYMREF)) {
Just like we punted for S_ISLNK() in an earlier step, we for now
deal with regular refs in this step. OK.
> + if (!*trailing) {
> + ret = fsck_report_ref(o, &report,
> + FSCK_MSG_REF_MISSING_NEWLINE,
> + "missing newline");
> + goto cleanup;
> + }
> +
> + if (*trailing != '\n' || *(trailing + 1)) {
> + ret = fsck_report_ref(o, &report,
> + FSCK_MSG_TRAILING_REF_CONTENT,
> + "trailing garbage in ref");
> + goto cleanup;
> + }
Not limited to this patch, but isn't fsck_report_ref() misdesigned,
or is it just they are used poorly in these patches? In these two
callsites, the message string parameter does not give any more
information than what the FSCK_MSG_* enum gives.
In fact, MSG_REF_MISSING_NEWLINE at least says that the complaint is
about refs, but "missing newline" does not even say from what the
newline is missing. For TRAILING_REF_CONTENT, people may expect to
see what garbage follows the expected contents, but that information
(i.e. contents of *trailing) is lost here.
