On Wed, Aug 10, 2022 at 03:08:14PM -0700, Junio C Hamano wrote:
> I was almost sure that before we "unified" the codepath for normal
> tree reading and the one used for fsck in a mistaken way, which was
> fixed in this series, we were catching these anomalous mode bits,
> but the suspected regression is too long ago that it does not make a
> practical difference if it was always broken or it was broken long
> time ago. The risk to start complaining on existing projects is the
> same either way.
I agree with the "it was so long ago it does not matter", but for the
sake of posterity, here's what my digging found:
- we got the mode fsck checks in 64071805ed (git-fsck-cache: be
stricter about "tree" objects, 2005-07-27), though there is a proto
version that is even a little older. Back then we were using a
linked list to hold the parsed tree entries (!), but it was parsed
by a central spot in parse_tree_buffer().
- that linked list code went away in 15b5536ee4 (Remove last vestiges
of generic tree_entry_list, 2006-05-29). But...
- ...by then we already had 1b0c7174a1 (tree/diff header cleanup.,
2006-03-29), which had tree_entry_extract(). And that commit
introduced canon_mode, including the same "set unexpected things to
a default", though of course back then it waas S_IFDIR since
gitlinks didn't exist. ;)
- that canon_mode() was just a rename from DIFF_FILE_CANON_MODE(),
which ultimately came from 67574c403f ([PATCH] diff: mode bits
fixes, 2005-06-01)
So some form of canon_mode() does predate the fsck checks, but I _think_
the fsck code was using the old linked-list version until 15b5536ee4,
and would not have been affected. So yes, there were probably 10 months
in 2005-2006 where we would have detected these. :)
Again, probably not important, but it was interesting for me at least to
see the evolution of the tree code. Most of those changes predate my
involvement with the code.
-Peff
