git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stan Hu <stanhu@gmail.com>
Cc: git@vger.kernel.org,  Patrick Steinhardt <ps@pks.im>,
	 Christian Couder <christian.couder@gmail.com>
Subject: Re: [PATCH 1/2] completion: refactor existence checks for special refs
Date: Sun, 03 Dec 2023 22:15:15 +0900	[thread overview]
Message-ID: <xmqqedg34ecc.fsf@gitster.g> (raw)
In-Reply-To: <20231130202404.89791-2-stanhu@gmail.com> (Stan Hu's message of "Thu, 30 Nov 2023 12:24:03 -0800")

Stan Hu <stanhu@gmail.com> writes:

> In preparation for the reftable backend, this commit introduces a
> '__git_ref_exists' function that continues to use 'test -f' to
> determine whether a given ref exists in the local filesystem.

I do not think git_ref_exists is a good name for what this one does.
The name adds undue cognitive load on readers.  As far as I can
tell, with this helper function, you are interested in handling only
pseudorefs like $GIT_DIR/FOOBAR_HEAD (oh, retitle the patch to call
them "pseudorefs", not "special refs", by the way), and that is why
you can get away with a simple

    [ -f "$__git_repo_path/$ref" ]

without bothering to check the packed-refs file.  The checks this
patch replace to calls to this helper functions in the original make
it clear, simply because they spell out what they are checking, like
"CHERRY_PICK_HEAD", why a mere filesystem check was sufficient, but
once you give an overly generic name like "ref-exists", it becomes
tempting to (ab|mis)use it to check for branches and tags, which is
not your intention at all, and the implementation does not work well
for that purpose.

> Each caller of '__git_ref_exists' must call '__git_find_repo_path`
> first. '_git_restore' already used 'git rev-parse HEAD', but to use
> '__git_ref_exists' insert a '__git_find_repo_path' at the start.

To whom do you think the above piece of information is essential for
them to work?  Whoever updates the completion script, finds existing
use of __git_ref_exists, and thinks the helper would be useful for
their own use.  To them, the above needs be in the in-code comment
to make it discoverable.  It is OK to have it also in the proposed
log message, but it is not as essential, especially if you have it
in-code anyway.

Another thing you would need to make sure that the potential users
of this helpers understand is of course this is meant to be used
only on pseudorefs.  You can of course do so with an additional
in-code comment, but giving a more appropriate name to the helper
would be the easiest and simplest, e.g. __git_pseudoref_exists or
something.

> Reviewed-by: Patrick Steinhardt <ps@pks.im>
> Reviewed-by: Christian Couder <christian.couder@gmail.com>
> Signed-off-by: Stan Hu <stanhu@gmail.com>
> ---
>  contrib/completion/git-completion.bash | 20 +++++++++++++++-----
>  1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 13a39ebd2e..9fbdc13f9a 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -122,6 +122,15 @@ __git ()
>  		${__git_dir:+--git-dir="$__git_dir"} "$@" 2>/dev/null
>  }
>  
> +# Runs git in $__git_repo_path to determine whether a ref exists.
> +# 1: The ref to search
> +__git_ref_exists ()
> +{
> +	local ref=$1
> +
> +	[ -f "$__git_repo_path/$ref" ]
> +}

  parent reply	other threads:[~2023-12-03 13:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-30 20:24 [PATCH 0/2] completion: refactor and support reftables backend Stan Hu
2023-11-30 20:24 ` [PATCH 1/2] completion: refactor existence checks for special refs Stan Hu
2023-11-30 20:24   ` [PATCH 2/2] completion: stop checking for reference existence via `test -f` Stan Hu
2023-12-01  7:49     ` Patrick Steinhardt
2023-12-03 13:15   ` Junio C Hamano [this message]
2023-12-01  7:49 ` [PATCH 0/2] completion: refactor and support reftables backend Patrick Steinhardt
2023-12-07  6:06 ` [PATCH v2 " Stan Hu
2023-12-07  6:06   ` [PATCH v2 1/2] completion: refactor existence checks for pseudorefs Stan Hu
2023-12-08  8:24     ` Patrick Steinhardt
2023-12-07  6:06   ` [PATCH v2 2/2] completion: support pseudoref existence checks for reftables Stan Hu
2023-12-19 22:14 ` [PATCH v3 0/2] completion: refactor and support reftables backend Stan Hu
2023-12-19 22:14   ` [PATCH v3 1/2] completion: refactor existence checks for pseudorefs Stan Hu
2024-01-13 21:07     ` SZEDER Gábor
2023-12-19 22:14   ` [PATCH v3 2/2] completion: support pseudoref existence checks for reftables Stan Hu
2023-12-20  0:48   ` [PATCH v3 0/2] completion: refactor and support reftables backend Junio C Hamano

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=xmqqedg34ecc.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=ps@pks.im \
    --cc=stanhu@gmail.com \
    /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).