From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: <git@vger.kernel.org>, Elijah Newren <newren@gmail.com>,
Calvin Wan <calvinwan@google.com>
Subject: Re: [PATCH 2/3] var: add attributes files locations
Date: Thu, 22 Jun 2023 14:17:20 -0700 [thread overview]
Message-ID: <xmqqcz1ndwnz.fsf@gitster.g> (raw)
In-Reply-To: <20230622195059.320593-3-sandals@crustytoothpaste.net> (brian m. carlson's message of "Thu, 22 Jun 2023 19:50:58 +0000")
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> -static const char *git_etc_gitattributes(void)
> +const char *git_etc_gitattributes(void)
> {
> static const char *system_wide;
> if (!system_wide)
> @@ -878,7 +878,7 @@ static const char *git_etc_gitattributes(void)
> return system_wide;
> }
>
> -static const char *get_home_gitattributes(void)
> +const char *get_home_gitattributes(void)
> {
> if (!git_attributes_file)
> git_attributes_file = xdg_config_home("attributes");
> @@ -886,7 +886,7 @@ static const char *get_home_gitattributes(void)
> return git_attributes_file;
> }
These are sensible, but ...
> -static int git_attr_system(void)
> +int git_attr_system(void)
> {
> return !git_env_bool("GIT_ATTR_NOSYSTEM", 0);
> }
... even though this is not exactly a new problem, but this function
is misnamed and exposing it outside the file is not exactly nice.
We would want to rename it to perhaps git_attr_use_system() or
something? "allow" would also work as a verb there, but the point
is without any verb, it is easily confused with what the function
git_etc_git_attributes() wants to do.
side note: arguably the "etc-gitattributes" and "home-gitattributes"
are also suboptimal public names to give these functions, even
though they are fine as long as they are confined in a subsystem.
For global functions, it would be better to give name that match
what the end-users think of them, when possible. The former would
be "git_attr_system()" and the latter would be "git_attr_global()".
> struct git_var {
> const char *name;
> const char *(*read)(int);
> + int free;
> };
> static struct git_var git_vars[] = {
> - { "GIT_COMMITTER_IDENT", git_committer_info },
> - { "GIT_AUTHOR_IDENT", git_author_info },
> - { "GIT_EDITOR", editor },
> - { "GIT_SEQUENCE_EDITOR", sequence_editor },
> - { "GIT_PAGER", pager },
> - { "GIT_DEFAULT_BRANCH", default_branch },
> - { "GIT_SHELL_PATH", shell_path },
> + { "GIT_COMMITTER_IDENT", git_committer_info, 0 },
> + { "GIT_AUTHOR_IDENT", git_author_info, 0 },
> + { "GIT_EDITOR", editor, 0 },
> + { "GIT_SEQUENCE_EDITOR", sequence_editor, 0 },
> + { "GIT_PAGER", pager, 0 },
> + { "GIT_DEFAULT_BRANCH", default_branch, 0 },
> + { "GIT_SHELL_PATH", shell_path, 0 },
> + { "GIT_ATTR_SYSTEM", git_attr_val_system, 1 },
> + { "GIT_ATTR_GLOBAL", git_attr_val_global, 1 },
> { "", NULL },
> };
I am not sure if the "free" (which stands for "allocated") is worth
adding here for such a single-use-and-then-exit command. It is a
maintenance burden for anybody who adds new variables.
Either mark these values with UNLEAK(), or make the ones that do
not allocate xstrdup() so that they can be free'd blindly, would be
less unwieldy option, I guess.
> diff --git a/t/t0007-git-var.sh b/t/t0007-git-var.sh
> index 270bd4e512..6a2cc94abb 100755
> --- a/t/t0007-git-var.sh
> +++ b/t/t0007-git-var.sh
> @@ -159,6 +159,26 @@ test_expect_success MINGW 'GIT_SHELL_PATH points to a suitable shell' '
> grep "sh\$" shell
> '
>
> +test_expect_success 'GIT_ATTR_SYSTEM points to the correct location' '
I found it somewhat funny to claim we are checking that the variable
points to the "correct" location, while the test is happy as long as
it points at any path.
> + test_must_fail env GIT_ATTR_NOSYSTEM=1 git var GIT_ATTR_SYSTEM &&
> + (
> + sane_unset GIT_ATTR_NOSYSTEM &&
> + git var GIT_ATTR_SYSTEM >path &&
> + test "$(cat path)" != ""
> + )
> +'
> +
> +test_expect_success 'GIT_ATTR_GLOBAL points to the correct location' '
> + TRASHDIR="$(test-tool path-utils normalize_path_copy "$(pwd)")" &&
> + XDG_CONFIG_HOME="$TRASHDIR/.config" git var GIT_ATTR_GLOBAL >path &&
> + test "$(cat path)" = "$TRASHDIR/.config/git/attributes" &&
> + (
> + sane_unset XDG_CONFIG_HOME &&
> + HOME="$TRASHDIR" git var GIT_ATTR_GLOBAL >path &&
> + test "$(cat path)" = "$TRASHDIR/.config/git/attributes"
> + )
> +'
This one is much less funny ;-) Very nice.
next prev parent reply other threads:[~2023-06-22 21:17 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-22 19:50 [PATCH 0/3] Additional variables for git var brian m. carlson
2023-06-22 19:50 ` [PATCH 1/3] var: add support for listing the shell brian m. carlson
2023-06-22 20:42 ` Eric Sunshine
2023-06-22 21:05 ` Junio C Hamano
2023-06-22 21:13 ` Eric Sunshine
2023-06-22 21:25 ` brian m. carlson
2023-06-22 21:41 ` Junio C Hamano
2023-06-22 21:20 ` brian m. carlson
2023-06-22 19:50 ` [PATCH 2/3] var: add attributes files locations brian m. carlson
2023-06-22 20:19 ` Derrick Stolee
2023-06-22 21:17 ` brian m. carlson
2023-06-22 21:37 ` Junio C Hamano
2023-06-22 21:17 ` Junio C Hamano [this message]
2023-06-22 21:18 ` Eric Sunshine
2023-06-22 21:30 ` brian m. carlson
2023-06-22 21:21 ` Eric Sunshine
2023-06-22 19:50 ` [PATCH 3/3] var: add config file locations brian m. carlson
2023-06-22 21:35 ` Eric Sunshine
2023-06-26 19:00 ` [PATCH v2 0/7] Additional variables for git var brian m. carlson
2023-06-26 19:00 ` [PATCH v2 1/7] t: add a function to check executable bit brian m. carlson
2023-06-26 19:00 ` [PATCH v2 2/7] var: add support for listing the shell brian m. carlson
2023-06-26 19:00 ` [PATCH v2 3/7] var: format variable structure with C99 initializers brian m. carlson
2023-06-26 19:00 ` [PATCH v2 4/7] var: adjust memory allocation for strings brian m. carlson
2023-06-26 19:56 ` Junio C Hamano
2023-06-26 19:00 ` [PATCH v2 5/7] attr: expose and rename accessor functions brian m. carlson
2023-06-26 19:58 ` Junio C Hamano
2023-06-26 19:00 ` [PATCH v2 6/7] var: add attributes files locations brian m. carlson
2023-06-27 7:05 ` Jeff King
2023-06-27 16:12 ` brian m. carlson
2023-06-27 17:56 ` Junio C Hamano
2023-06-27 20:16 ` Jeff King
2023-06-26 19:00 ` [PATCH v2 7/7] var: add config file locations brian m. carlson
2023-06-26 20:02 ` Junio C Hamano
2023-06-27 16:18 ` [PATCH v3 0/8] Additional variables for git var brian m. carlson
2023-06-27 16:18 ` [PATCH v3 1/8] var: mark unused parameters in git_var callbacks brian m. carlson
2023-06-27 16:18 ` [PATCH v3 2/8] t: add a function to check executable bit brian m. carlson
2023-06-27 16:18 ` [PATCH v3 3/8] var: add support for listing the shell brian m. carlson
2023-06-27 16:18 ` [PATCH v3 4/8] var: format variable structure with C99 initializers brian m. carlson
2023-06-27 16:18 ` [PATCH v3 5/8] var: adjust memory allocation for strings brian m. carlson
2023-06-27 16:19 ` [PATCH v3 6/8] attr: expose and rename accessor functions brian m. carlson
2023-06-27 16:19 ` [PATCH v3 7/8] var: add attributes files locations brian m. carlson
2023-06-27 16:19 ` [PATCH v3 8/8] var: add config file locations brian m. carlson
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=xmqqcz1ndwnz.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=calvinwan@google.com \
--cc=git@vger.kernel.org \
--cc=newren@gmail.com \
--cc=sandals@crustytoothpaste.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).