Subject: Re: [PATCH v2 2/4] ref: add regular ref content check for files backend

From: Patrick Steinhardt <[email-masked]>
Date: Wed, 28 Aug 2024 14:50:06 +0200

On Tue, Aug 27, 2024 at 11:21:34AM -0700, Junio C Hamano wrote:
> shejialuo <[email-masked]> writes:
> > @@ -170,6 +173,12 @@
> >  `nullSha1`::
> >  	(WARN) Tree contains entries pointing to a null sha1.
> >  
> > +`refMissingNewline`::
> > +	(INFO) A valid ref does not end with newline.
> > +
> > +`trailingRefContent`::
> > +	(INFO) A ref has trailing contents.
> > +
> >  `treeNotSorted`::
> >  	(ERROR) A tree is not properly sorted.
> 
> There is no mention of "you shouldn't promote these to error" here,
> which is good.  But wouldn't we want to tell users to report such
> curiously formatted loose refs, after figuring out who created them,
> to help us to eventually make the check stricter in the future?
> 
> Git 3.0 boundary might be a good time to tighten interoperability
> rules such that we won't accept anything we wouldn't have written
> ourselves (not limited to loose ref format, but this applies to
> anything on-disk or on-wire), but we'd need enough preparation if we
> want to be able to do so in the future.

I quite like this idea. Jialuo, would you maybe want to include another
patch on top that adds a paragraph to Documentation/BreakingChanges.txt?
It should note that this is not yet settled and depends on whether or
not we see complaints with your new checks.

I guess another prereq for the change is to integrate `git refs verify`
with git-fsck(1), because otherwise people likely wouldn't see the new
messages in the first place.

Patrick