Re: [PATCH 2/2] dir: improve naming of oid_stat fields in two structs

From: Jeff King <peff@peff.net>
Date: Mar 16, 2020, 19:20 UTC
Message-ID: <20200316192000.GB1073710@coredump.intra.peff.net>
In-Reply-To: <xmqqo8sw87xj.fsf@gitster.c.googlers.com>

On Mon, Mar 16, 2020 at 11:35:04AM -0700, Junio C Hamano wrote:

Show 19 quoted lines

> Junio C Hamano <gitster@pobox.com> 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