shejialuo <shejialuo@xxxxxxxxx> 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.
