git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org, toon@iotcl.com
Subject: Re: [PATCH v3 2/2] attr: add flag `-r|--revisions` to work with revisions
Date: Sat, 17 Dec 2022 08:45:22 +0900	[thread overview]
Message-ID: <xmqqr0wykj59.fsf@gitster.g> (raw)
In-Reply-To: <20221216093552.3171319-3-karthik.188@gmail.com> (Karthik Nayak's message of "Fri, 16 Dec 2022 10:35:52 +0100")

Karthik Nayak <karthik.188@gmail.com> writes:

> ... to optionally allow the users
> to check attributes against paths from older commits.

The above makes it sounds as if attributes are taken from places
that are unrelated to the "older commits" and the point of the
change allows "paths in an older commit" to be inspected.  I do not
think that is what is going on, though.  Isn't the point of the patch
to take attributes definitions from arbitrary tree-ish?

Also, "older commits" is misleading.  You may be chasing a bug in
older codebase and you have a checkout of an old commit, but you
know you have corrected the attributes definition since that old
version.  In such a case, you may want to take the attributes from
the latest release and apply to the currently checked out working
tree or commit that is older.  That is checking attributes taken
from newer commit.

	... to check attributes taken from a commit other than HEAD
	against paths.

or something, perhaps?

> Add a new flag `--revision`/`-r` which will allow users to check the
> attributes against a tree-ish revision.

"tree-ish revision" sounds a bit strange.  We used to use "revision"
very loosely to mean an "object name", but we weaned ourselves off
of such a loose terminology over time.  These days, the word
"revision" only refers to a commit (or commit-ish).

I would understand "... against a tree-ish."  If you feared that
"tree-ish" is not widely understood (which is a valid concern), then
"... against a commit (actually any tree-ish would do)" is probably
what I would write.

> When the user uses this flag, we
> go through the stack of .gitattributes files but instead of checking the
> current working tree and/or in the index, we check the blobs from the
> provided tree-ish object. This allows the command to also be used in
> bare repositories.

Good.

> Since we use a tree-ish object, the user can pass "-r HEAD:subdirectory"
> and all the attributes will be looked up as if subdirectory was the root
> directory of the repository.

Is this meant to explain a feature, or a misfeature?  In other
words, when would this be useful?  I would omit this paragraph if I
were writing it.

> We cannot use the `<rev>:<path>` syntax like the one used in `git show`
> because any non-flag parameter before `--` is treated as an attribute
> and any parameter after `--` is treated as a pathname.

I do not see what this one wants to say.  <rev>:<path> is an
established way to name an object that is sitting at the <path> in
the tree-ish whose name is <rev>.  The user can use "-r
<rev>:<path>" and if the <path> in <rev> is a tree, then all the
attributes will be looked up as if <path> were the root.  So the
users can use the <rev>:<path> syntax, cannot they?

> Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
> Co-authored-by: toon@iotcl.com

Co-authoring is fine, but as one of the copyright holder, the other
author needs to sign it off, too.

  reply	other threads:[~2022-12-16 23:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-16  9:35 [PATCH v3 0/2] check-attr: add support to work with revisions Karthik Nayak
2022-12-16  9:35 ` [PATCH v3 1/2] t0003: move setup for `--all` into new block Karthik Nayak
2022-12-16  9:35 ` [PATCH v3 2/2] attr: add flag `-r|--revisions` to work with revisions Karthik Nayak
2022-12-16 23:45   ` Junio C Hamano [this message]
2022-12-17 15:23     ` Karthik Nayak
2022-12-21  6:10     ` Toon Claes
2022-12-17  0:33   ` Junio C Hamano
2022-12-17 15:27     ` Karthik Nayak
2022-12-16 16:17 ` [PATCH v3 0/2] check-attr: add support " Ævar Arnfjörð Bjarmason
2022-12-16 22:38   ` Junio C Hamano
2022-12-19  8:45     ` Ævar Arnfjörð Bjarmason
2022-12-16 23:28   ` Junio C Hamano
2022-12-17 14:46   ` Karthik Nayak
2022-12-16 23:26 ` Junio C Hamano
2022-12-17 14:49   ` Karthik Nayak
2022-12-17 10:53 ` Phillip Wood
2022-12-17 14:52   ` Karthik Nayak
2022-12-19  9:45 ` Ævar Arnfjörð Bjarmason
2022-12-19 13:16   ` Karthik Nayak

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=xmqqr0wykj59.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=karthik.188@gmail.com \
    --cc=toon@iotcl.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).