Git Mailing List Archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "ZheNing Hu via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Martin Monperrus" <martin.monperrus@gnieh.org>,
	"ZheNing Hu" <adlternative@gmail.com>
Subject: Re: [PATCH 1/2] ls-files: add %(objecttype) atom to format option
Date: Sun, 14 May 2023 22:00:56 -0700	[thread overview]
Message-ID: <xmqqednicho7.fsf@gitster.g> (raw)
In-Reply-To: <3f8884457d3628439aa9e6800c976f5a597cdda3.1683969100.git.gitgitgadget@gmail.com> (ZheNing Hu via GitGitGadget's message of "Sat, 13 May 2023 09:11:38 +0000")

"ZheNing Hu via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: ZheNing Hu <adlternative@gmail.com>
>
> Sometimes users may want to align the feature of
> `git ls-files --format` with that of `git ls-tree --format`,
> but the %(objecttype) atom is missing in the format option
> of git ls-files compared to git ls-tree.

"Sometimes users may want to" sounds a bit awkward; even if no user
notices that the two very similar commands supports different subset
of the vocabulary without good reason, wouldn't we want to align the
feature set of these two commands?

> Therefore, the %(objecttype) atom is added to the format option
> of git ls-files, which can be used to obtain the object type
> of the file which is recorded in the index.

And from that point of view, this conclusion has a bit more to think
about.  Is the %(objecttype) singled out here only because somebody
happened to have complained on the list, or did somebody went into
the list of supported atoms between two commands and considered what
is missing from one but is supported by the other, and concluded that
only adding this one atom to ls-files would make the two consistent?

I would not complain if it were the former, but it must be explained
here in the proposed log message.  That would encourage others to do
a follow-on work to complete the comparison to fill the gaps on the
both sides.  If it were the former, saying so explicitly in the
proposed log message will save others---otherwise they may try to do
the comparison themselves only to find that this was the last one
remaining discrepancy.

> Signed-off-by: ZheNing Hu <adlternative@gmail.com>
> ---
>  Documentation/git-ls-files.txt | 2 ++
>  builtin/ls-files.c             | 2 ++
>  t/t3013-ls-files-format.sh     | 7 +++++++
>  3 files changed, 11 insertions(+)
>
> diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> index 1abdd3c21c5..4356c094cec 100644
> --- a/Documentation/git-ls-files.txt
> +++ b/Documentation/git-ls-files.txt
> @@ -270,6 +270,8 @@ interpolated.  The following "fieldname" are understood:
>  
>  objectmode::
>  	The mode of the file which is recorded in the index.
> +objecttype::
> +	The object type of the file which is recorded in the index.
>  objectname::
>  	The name of the file which is recorded in the index.
>  stage::
> diff --git a/builtin/ls-files.c b/builtin/ls-files.c
> index 625f48f0d61..6ff764cda18 100644
> --- a/builtin/ls-files.c
> +++ b/builtin/ls-files.c
> @@ -272,6 +272,8 @@ static size_t expand_show_index(struct strbuf *sb, const char *start,
>  		strbuf_addf(sb, "%06o", data->ce->ce_mode);
>  	else if (skip_prefix(start, "(objectname)", &p))
>  		strbuf_add_unique_abbrev(sb, &data->ce->oid, abbrev);
> +	else if (skip_prefix(start, "(objecttype)", &p))
> +		strbuf_addstr(sb, type_name(object_type(data->ce->ce_mode)));
>  	else if (skip_prefix(start, "(stage)", &p))
>  		strbuf_addf(sb, "%d", ce_stage(data->ce));
>  	else if (skip_prefix(start, "(eolinfo:index)", &p))
> diff --git a/t/t3013-ls-files-format.sh b/t/t3013-ls-files-format.sh
> index ef6fb53f7f1..3a1da3d6697 100755
> --- a/t/t3013-ls-files-format.sh
> +++ b/t/t3013-ls-files-format.sh
> @@ -38,6 +38,13 @@ test_expect_success 'git ls-files --format objectname v.s. -s' '
>  	test_cmp expect actual
>  '
>  
> +test_expect_success 'git ls-files --format objecttype' '
> +	git ls-files --format="%(objectname)" o1.txt o4.txt o6.txt >objectname &&
> +	git cat-file --batch-check="%(objecttype)" >expect <objectname &&
> +	git ls-files --format="%(objecttype)" o1.txt o4.txt o6.txt >actual &&
> +	test_cmp expect actual
> +'
> +
>  test_expect_success 'git ls-files --format v.s. --eol' '
>  	git ls-files --eol >tmp &&
>  	sed -e "s/	/ /g" -e "s/  */ /g" tmp >expect 2>err &&

  reply	other threads:[~2023-05-15  5:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-13  9:11 [PATCH 0/2] ls-files: align format atoms with git ls-tree ZheNing Hu via GitGitGadget
2023-05-13  9:11 ` [PATCH 1/2] ls-files: add %(objecttype) atom to format option ZheNing Hu via GitGitGadget
2023-05-15  5:00   ` Junio C Hamano [this message]
2023-05-18 10:02     ` ZheNing Hu
2023-05-13  9:11 ` [PATCH 2/2] ls-files: add %(objectsize) " ZheNing Hu via GitGitGadget
2023-05-15  5:03   ` Junio C Hamano
2023-05-23  9:00 ` [PATCH v2] ls-files: aligin format atoms wtih ls-tree ZheNing Hu via GitGitGadget

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=xmqqednicho7.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=adlternative@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=martin.monperrus@gnieh.org \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).