> > 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".
