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

From: Junio C Hamano <[email-masked]>
Date: Wed, 28 Aug 2024 09:45:34 -0700

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?
>
> From the review from the Patrick, I will add another patch in the
> "Documentation/BreakingChanges.txt" later.

As that documentation is not end-user facing, it is orthogonal and
unrelated.

What I meant was that we need to tell the user that the refs they
have (and the third-party tools they used to create them) may be
declared invalid in a future version of Git and they would want to
report it, in order to influence our possible future direction.  And
we need to do so in an end-user facing documentation (i.e. the part
of the patch quoted above) and/or in the info messages themselves.