Re: [GSoC][PATCH v11 10/10] fsck: add ref content check for files backend

The "parse_loose_ref_contents" will return the referent. In this function,
it will skip the prefix "ref:" to get the pointee. If there are some trailing
garbage, it will be reported by the "files_fsck_symref_target".

"files_fsck_symref_target" will use "check_refname_format" function
to check the pointee. For example, if the content is "ref: refs/heads/
master garbage". The "refs/heads/master garbage" is a bad name.

However, in my design, the trailing spaces or newline will be ignored,
I thought we may not report this problem. And I use "strbuf_rtrim" here
to ignore spaces and newlines.

And I think there are some differences between symbolic refs and
regular refs when parsing. For regular refs, git will ignore any trailing
garbage, however for symbolic refs, git will only ignore the newlines
and spaces garbage. And git will not parse "refs/heads/master gar",
it's an error here. But for regular refs, for example "edaca... garbage",
git will parse it normally without any warnings.

So question comes here, should we warn the user about the trailing
newlines or spaces. When using "git symbolic-ref refs/heads/maint
refs/heads/main", the "refs/heads/maint" will contain the newline
'\n' here and git also accepts content without newline '\n'. And I
think we should not warn the user about one newline or no newline.

In my opinion, we should do this. It's not hard to do that. We only
warn the user for the following two situations:

1. two or more newlines.
2. one or more spaces.

I will improve code in the next version.

Well, I have changed my idea here. Sorry for that. If we report this as
warning, what is the difference between the following two cases:

1. "ref: refs/heads/master      garbage     "
2. "ref: refs/heads/master      garbage"

For 1, if we do this, we will first report it has the extra spaces and then
report it's a bad refname. For 2, we will report it's a bad refname. I think
we should not report extra spaces or newlines here even with the error
type "warning".