On Mon, Mar 16, 2020 at 11:35:04AM -0700, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > The potential for confusion with "path to these files" is real, I > > would think, so they may benefit from some prefix. > > > > But instead of basing the prefix on their type, can we name it after > > what this struct holds about the excludes file, and what the data > > the struct holds is used for? Is "oidst" something that conveys it > > well to the readers of the code? > > ... > > In a sense, this struct is a pared down version of cache_entry that > > keeps the filesystem stat data to allow us quickly find if the path > > was modified, and also lets us know if two contents are the same > > without comparing bytes. It is a mechanism for us to tell validity > > of our cached data. "struct path_validity" perhaps? I dunno. > > I think "path_validity", while it probably is much better than > "oid_stat", is a horrible name for the struct, so I'd welcome > suggestions from third-party ;-) We also have "struct stat_validity" already, which is an even more pared-down version of the same concept. :) > But I think renaming "ss_info_exclude" to "info_exclude_validity" > (or any name that talks about "info/exclude" and "validity") would > be a vast improvement, regardless of what the struct is called. Yeah. I think it is good to get rid of the "ss_", but it's probably not worth spending too many more brain cycles coming up with a perfect name. IMHO "info_exclude_validity" and "excludes_file_validity" seem quite descriptive. -Peff
