On Tue, Aug 27, 2024 at 11:21:34AM -0700, Junio C Hamano wrote: > 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? > > 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
