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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Karthik Nayak <karthik.188@xxxxxxxxx> writes:
>
> shejialuo <shejialuo@xxxxxxxxx> writes:
> > +     /*
> > +      * If the ref is a symref, we need to check the destination name and
> > +      * connectivity.
> > +      */
> > +     if (referent.len && (type & REF_ISSYMREF)) {
> > +             strbuf_addf(&pointee_path, "%s/%s", gitdir, referent.buf);
> > +             strbuf_rtrim(&referent);
> > +
> > +             ret = files_fsck_symref_target(o, refname.buf, referent.buf,
> > +                                            pointee_path.buf);
> > +             goto clean;
> > +     } else {
> > +             /*
> > +              * Only regular refs could have a trailing garbage. Should
> > +              * be reported as a warning.
> > +              */
>
> What happens if a symbolic reference has trailing garbage ?
>

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.

Thanks,
Jialuo




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux