All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "Sérgio Peixoto" <sergio.peixoto@gmail.com>
Cc: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
	"Brandon Williams" <bwilliams.eng@gmail.com>,
	git@vger.kernel.org
Subject: [PATCH] attr: do not mark queried macros as unset
Date: Fri, 18 Jan 2019 16:34:58 -0500	[thread overview]
Message-ID: <20190118213458.GB28808@sigill.intra.peff.net> (raw)
In-Reply-To: <20190118165800.GA9956@sigill.intra.peff.net>

On Fri, Jan 18, 2019 at 11:58:01AM -0500, Jeff King wrote:

> Now, on to the actual bug. The simplest reproduction is:
> 
>   (echo "[attr]foo bar"; echo "* foo") >.gitattributes
>   git check-attr foo file

Actually, even simpler is to just "binary", which is pre-defined as a
macro. :)

> which should report "foo" as set. This bisects to 60a12722ac (attr:
> remove maybe-real, maybe-macro from git_attr, 2017-01-27), and it seems
> like an unintentional regression there. I haven't yet poked into that
> commit to see what the fix will look like.

So here's the fix I came up with. +cc Duy, as this is really tangled
with his older 06a604e670.

-- >8 --
Subject: [PATCH] attr: do not mark queried macros as unset

Since 60a12722ac (attr: remove maybe-real, maybe-macro from git_attr,
2017-01-27), we will always mark an attribute macro (e.g., "binary")
that is specifically queried for as "unspecified", even though listing
_all_ attributes would display it at set. E.g.:

  $ echo "* binary" >.gitattributes

  $ git check-attr -a file
  file: binary: set
  file: diff: unset
  file: merge: unset
  file: text: unset

  $ git check-attr binary file
  file: binary: unspecified

The problem stems from an incorrect conversion of the optimization from
06a604e670 (attr: avoid heavy work when we know the specified attr is
not defined, 2014-12-28). There we tried in collect_some_attrs() to
avoid even looking at the attr_stack when the user has asked for "foo"
and we know that "foo" did not ever appear in any .gitattributes file.

It used a flag "maybe_real" in each attribute struct, where "real" meant
that the attribute appeared in an actual file (we have to make this
distinction because we also create an attribute struct for any names
that are being queried). But as explained in that commit message, the
meaning of "real" was tangled with some special cases around macros.

When 06a604e670 later refactored the macro code, it dropped maybe_real
entirely. This missed the fact that "maybe_real" could be unset for two
reasons: because of a macro, or because it was never found during
parsing. This had two results:

  - the optimization in collect_some_attrs() ceased doing anything
    meaningful, since it no longer kept track of "was it found during
    parsing"

  - worse, it actually kicked in when the caller _did_ ask about a macro
    by name, causing us to mark it as unspecified

It should be possible to salvage this optimization, but let's start with
just removing the remnants. It hasn't been doing anything (except
creating bugs) since 60a12722ac, and nobody seems to have noticed the
performance regression. It's more important to fix the correctness
problem clearly first.

I've added two tests here. The second one actually shows off the bug.
The test of "check-attr -a" is not strictly necessary, but we currently
do not test attribute macros much, and the builtin "binary" not at all.
So this increases our general test coverage, as well as making sure we
didn't mess up this related case.

Signed-off-by: Jeff King <peff@peff.net>
---
 attr.c                | 16 +---------------
 t/t0003-attributes.sh | 20 ++++++++++++++++++++
 2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/attr.c b/attr.c
index eaece6658d..57ced792f8 100644
--- a/attr.c
+++ b/attr.c
@@ -1092,7 +1092,7 @@ static void collect_some_attrs(const struct index_state *istate,
 			       const char *path,
 			       struct attr_check *check)
 {
-	int i, pathlen, rem, dirlen;
+	int pathlen, rem, dirlen;
 	const char *cp, *last_slash = NULL;
 	int basename_offset;
 
@@ -1113,20 +1113,6 @@ static void collect_some_attrs(const struct index_state *istate,
 	all_attrs_init(&g_attr_hashmap, check);
 	determine_macros(check->all_attrs, check->stack);
 
-	if (check->nr) {
-		rem = 0;
-		for (i = 0; i < check->nr; i++) {
-			int n = check->items[i].attr->attr_nr;
-			struct all_attrs_item *item = &check->all_attrs[n];
-			if (item->macro) {
-				item->value = ATTR__UNSET;
-				rem++;
-			}
-		}
-		if (rem == check->nr)
-			return;
-	}
-
 	rem = check->all_attrs_nr;
 	fill(path, pathlen, basename_offset, check->stack, check->all_attrs, rem);
 }
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index 22499bce5f..71e63d8b50 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -322,4 +322,24 @@ test_expect_success 'bare repository: test info/attributes' '
 	)
 '
 
+test_expect_success 'binary macro expanded by -a' '
+	echo "file binary" >.gitattributes &&
+	cat >expect <<-\EOF &&
+	file: binary: set
+	file: diff: unset
+	file: merge: unset
+	file: text: unset
+	EOF
+	git check-attr -a file >actual &&
+	test_cmp expect actual
+'
+
+
+test_expect_success 'query binary macro directly' '
+	echo "file binary" >.gitattributes &&
+	echo file: binary: set >expect &&
+	git check-attr binary file >actual &&
+	test_cmp expect actual
+'
+
 test_done
-- 
2.20.1.691.ge06e0a624f


  reply	other threads:[~2019-01-18 21:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-17 15:47 Change on check-attr behavior Sérgio Peixoto
2019-01-17 16:07 ` Jeff King
2019-01-18  9:41   ` Sérgio Peixoto
2019-01-18 16:58     ` Jeff King
2019-01-18 21:34       ` Jeff King [this message]
2019-01-18 21:46         ` [PATCH] attr: do not mark queried macros as unset Jeff King
2019-01-18 22:19           ` Stefan Beller
2019-01-22  7:19             ` Jeff King
2019-01-22  9:50               ` Duy Nguyen
2019-01-22 22:00           ` Junio C Hamano
2019-01-21 10:05         ` Duy Nguyen
2019-01-22  7:21           ` Jeff King
2019-01-22  9:34         ` Duy Nguyen
2019-01-22 21:48         ` Junio C Hamano
2019-01-23  5:40           ` Jeff King

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=20190118213458.GB28808@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=bwilliams.eng@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    --cc=sergio.peixoto@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 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.