From: Junio C Hamano <gitster@pobox.com>
To: Matheus Tavares Bernardino <matheus.bernardino@usp.br>
Cc: git <git@vger.kernel.org>, "René Scharfe" <l.s.r@web.de>,
"Jeff King" <peff@peff.net>
Subject: Re: [PATCH 2/2] dir: improve naming of oid_stat fields in two structs
Date: Mon, 16 Mar 2020 11:35:04 -0700 [thread overview]
Message-ID: <xmqqo8sw87xj.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <xmqqsgi8882t.fsf@gitster.c.googlers.com> (Junio C. Hamano's message of "Mon, 16 Mar 2020 11:31:54 -0700")
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 ;-)
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.
next prev parent reply other threads:[~2020-03-16 18:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-16 3:47 [PATCH 0/2] dir: update outdated fields and comments about oid_stat Matheus Tavares
2020-03-16 3:47 ` [PATCH 1/2] dir: fix outdated comment on add_patterns() Matheus Tavares
2020-03-16 3:47 ` [PATCH 2/2] dir: improve naming of oid_stat fields in two structs Matheus Tavares
2020-03-16 6:17 ` Junio C Hamano
2020-03-16 12:31 ` Patryk Obara
2020-03-16 17:22 ` Matheus Tavares Bernardino
2020-03-16 18:31 ` Junio C Hamano
2020-03-16 18:35 ` Junio C Hamano [this message]
2020-03-16 19:20 ` Jeff King
2020-03-17 18:57 ` [PATCH v2 0/3] dir: update outdated field names and comments about oid_stat Matheus Tavares
2020-03-17 18:57 ` [PATCH v2 1/3] dir: fix outdated comment on add_patterns() Matheus Tavares
2020-03-17 18:57 ` [PATCH v2 2/3] dir: improve naming of oid_stat fields in two structs Matheus Tavares
2020-03-17 18:57 ` [PATCH v2 3/3] dir: update outdated comments about untracked cache Matheus Tavares
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqo8sw87xj.fsf@gitster.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=l.s.r@web.de \
--cc=matheus.bernardino@usp.br \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.