threads / patch / 50345

v3, 3 partsAdd tests for describe with --work-tree

Subject: [PATCH v3 1/3] Add tests for describe with --work-tree

## tl;dr

15 messages between Jan 29, 2019 and Jan 30, 2019. Diffs are folded; open one to read it.

replies: 14people: 4as markdown or json

Sebastian Staudt· Jan 29, 2019, 05:18 UTC · lore

The dirty ones are already passing, but just because describe is comparing with the wrong working tree.

Signed-off-by: Sebastian Staudt <koraktor@gmail.com>
---
 t/t6120-describe.sh | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)
Show changes to t/t6120-describe.sh +33 −0
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index d639d94696..c863c4f600 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -145,14 +145,38 @@ check_describe A-* HEAD
 
 check_describe "A-*[0-9a-f]" --dirty
 
+test_expect_success 'describe --dirty with --work-tree' "
+	(
+		cd '$TEST_DIRECTORY' &&
+		git --git-dir '$TRASH_DIRECTORY/.git' --work-tree '$TRASH_DIRECTORY' describe --dirty >'$TRASH_DIRECTORY/out'
+	) &&
+	grep 'A-\d\+-g[0-9a-f]\+' '$TRASH_DIRECTORY/out'
+"
+
 test_expect_success 'set-up dirty work tree' '
 	echo >>file
 '
 
 check_describe "A-*[0-9a-f]-dirty" --dirty
 
+test_expect_success 'describe --dirty with --work-tree' "
+	(
+		cd '$TEST_DIRECTORY' &&
+		git --git-dir '$TRASH_DIRECTORY/.git' --work-tree '$TRASH_DIRECTORY' describe --dirty >'$TRASH_DIRECTORY/out'
+	) &&
+	grep 'A-\d\+-g[0-9a-f]\+-dirty' '$TRASH_DIRECTORY/out'
+"
+
 check_describe "A-*[0-9a-f].mod" --dirty=.mod
 
+test_expect_success 'describe --dirty=.mod with --work-tree' "
+	(
+		cd '$TEST_DIRECTORY' &&
+		git --git-dir '$TRASH_DIRECTORY/.git' --work-tree '$TRASH_DIRECTORY' describe --dirty=.mod >'$TRASH_DIRECTORY/out'
+	) &&
+	grep 'A-\d\+-g[0-9a-f]\+.mod' '$TRASH_DIRECTORY/out'
+"
+
 test_expect_success 'describe --dirty HEAD' '
 	test_must_fail git describe --dirty HEAD
 '
@@ -303,12 +327,21 @@ test_expect_success 'describe chokes on severely broken submodules' '
 	mv .git/modules/sub1/ .git/modules/sub_moved &&
 	test_must_fail git describe --dirty
 '
+
 test_expect_success 'describe ignoring a broken submodule' '
 	git describe --broken >out &&
 	test_when_finished "mv .git/modules/sub_moved .git/modules/sub1" &&
 	grep broken out
 '
 
+test_expect_success 'describe with --work-tree ignoring a broken submodule' "
+	(
+		cd '$TEST_DIRECTORY' &&
+		git --git-dir '$TRASH_DIRECTORY/.git' --work-tree '$TRASH_DIRECTORY' describe --broken >'$TRASH_DIRECTORY/out'
+	) &&
+	grep broken '$TRASH_DIRECTORY/out'
+"
+
 test_expect_success 'describe a blob at a directly tagged commit' '
 	echo "make it a unique blob" >file &&
 	git add file && git commit -m "content in file" &&

-- 
2.20.1
Sebastian Staudt· Jan 29, 2019, 05:18 UTC · re: Sebastian Staudt · lore

[PATCH v3 2/3] Setup working tree in describe

This ensures the given working tree is used for --dirty.

The implementation of --broken uses diff-index which calls setup_work_tree() itself.

Signed-off-by: Sebastian Staudt <koraktor@gmail.com>
---
 builtin/describe.c | 1 +
 1 file changed, 1 insertion(+)
Show changes to builtin/describe.c +1 −0
diff --git a/builtin/describe.c b/builtin/describe.c
index cc118448ee..b5b7abdc8f 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -629,6 +629,7 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
 			struct argv_array args = ARGV_ARRAY_INIT;
 			int fd, result;
 
+			setup_work_tree();
 			read_cache();
 			refresh_index(&the_index, REFRESH_QUIET|REFRESH_UNMERGED,
 				      NULL, NULL, NULL);

-- 
2.20.1
Jeff King· Jan 29, 2019, 13:11 UTC · re: Sebastian Staudt · lore

Re: [PATCH v3 2/3] Setup working tree in describe

On Tue, Jan 29, 2019 at 06:18:58AM +0100, Sebastian Staudt wrote:
> Subject: Re: [PATCH v3 2/3] Setup working tree in describe

We usually write subjects as "area: do some thing" which is a little easier when scanning big lists of "git log --oneline".

I think it's key, too, that we only do this for the --dirty case, not always. So maybe:

  describe: setup working tree for --dirty
or something?
> This ensures the given working tree is used for --dirty.

There's been a lot of digging and discussion on the list about what happens if we don't do this. Could we summarize it here?

Perhaps:
  We don't use NEED_WORK_TREE when running the git-describe builtin,
  since you should be able to describe a commit even in a bare
  repository. However, the --dirty flag does need a working tree. Since
  we don't call setup_work_tree(), it uses whatever directory we happen
  to be in. That's unlikely to match our index, meaning we'd say "dirty"
  even when the real working tree is clean.
  We can fix that by calling setup_work_tree() once we know that the
  user has asked for --dirty.
> The implementation of --broken uses diff-index which calls
> setup_work_tree() itself.

If I hadn't just read the rest of the thread, I'd probably wonder why we are talking about --broken at all. Maybe:

  The --broken option similarly needs a working tree. But because the
  current implementation calls an external diff-index to do the work,
  we don't have to bother setting up the working tree in the
  git-describe process.
Show 12 quoted lines
> diff --git a/builtin/describe.c b/builtin/describe.c
> index cc118448ee..b5b7abdc8f 100644
> --- a/builtin/describe.c
> +++ b/builtin/describe.c
> @@ -629,6 +629,7 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
>  			struct argv_array args = ARGV_ARRAY_INIT;
>  			int fd, result;
>  
> +			setup_work_tree();
>  			read_cache();
>  			refresh_index(&the_index, REFRESH_QUIET|REFRESH_UNMERGED,
>  				      NULL, NULL, NULL);
The patch itself looks good. :)
-Peff
Junio C Hamano· Jan 29, 2019, 17:39 UTC · re: Jeff King · lore

Re: [PATCH v3 2/3] Setup working tree in describe

Jeff King <peff@peff.net> writes:
Show 13 quoted lines
> On Tue, Jan 29, 2019 at 06:18:58AM +0100, Sebastian Staudt wrote:
>
>> Subject: Re: [PATCH v3 2/3] Setup working tree in describe
>
> We usually write subjects as "area: do some thing" which is a little
> easier when scanning big lists of "git log --oneline".
>
> I think it's key, too, that we only do this for the --dirty case, not
> always. So maybe:
>
>   describe: setup working tree for --dirty
>
> or something?

Thanks as always for being an excellent reviewer who not just reviews but also gives good suggestions.

Show 44 quoted lines
>> This ensures the given working tree is used for --dirty.
>
> There's been a lot of digging and discussion on the list about what
> happens if we don't do this. Could we summarize it here?
>
> Perhaps:
>
>   We don't use NEED_WORK_TREE when running the git-describe builtin,
>   since you should be able to describe a commit even in a bare
>   repository. However, the --dirty flag does need a working tree. Since
>   we don't call setup_work_tree(), it uses whatever directory we happen
>   to be in. That's unlikely to match our index, meaning we'd say "dirty"
>   even when the real working tree is clean.
>
>   We can fix that by calling setup_work_tree() once we know that the
>   user has asked for --dirty.
>
>> The implementation of --broken uses diff-index which calls
>> setup_work_tree() itself.
>
> If I hadn't just read the rest of the thread, I'd probably wonder why we
> are talking about --broken at all. Maybe:
>
>   The --broken option similarly needs a working tree. But because the
>   current implementation calls an external diff-index to do the work,
>   we don't have to bother setting up the working tree in the
>   git-describe process.
>
>> diff --git a/builtin/describe.c b/builtin/describe.c
>> index cc118448ee..b5b7abdc8f 100644
>> --- a/builtin/describe.c
>> +++ b/builtin/describe.c
>> @@ -629,6 +629,7 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
>>  			struct argv_array args = ARGV_ARRAY_INIT;
>>  			int fd, result;
>>  
>> +			setup_work_tree();
>>  			read_cache();
>>  			refresh_index(&the_index, REFRESH_QUIET|REFRESH_UNMERGED,
>>  				      NULL, NULL, NULL);
>
> The patch itself looks good. :)
>
> -Peff
Eric Sunshine· Jan 29, 2019, 20:53 UTC · re: Jeff King · lore

Re: [PATCH v3 2/3] Setup working tree in describe

On Tue, Jan 29, 2019 at 8:12 AM Jeff King <peff@peff.net> wrote:
Show 17 quoted lines
> On Tue, Jan 29, 2019 at 06:18:58AM +0100, Sebastian Staudt wrote:
> > This ensures the given working tree is used for --dirty.
>
> There's been a lot of digging and discussion on the list about what
> happens if we don't do this. Could we summarize it here?
>
> Perhaps:
>
>   We don't use NEED_WORK_TREE when running the git-describe builtin,
>   since you should be able to describe a commit even in a bare
>   repository. However, the --dirty flag does need a working tree. Since
>   we don't call setup_work_tree(), it uses whatever directory we happen
>   to be in. That's unlikely to match our index, meaning we'd say "dirty"
>   even when the real working tree is clean.
>
>   We can fix that by calling setup_work_tree() once we know that the
>   user has asked for --dirty.

I have not particularly been following this thread, but this proposed commit message does an excellent job of summarizing and explaining the issue and making the fix obvious (so, now I don't have to go back and read the entire thread).

Show 10 quoted lines
> > The implementation of --broken uses diff-index which calls
> > setup_work_tree() itself.
>
> If I hadn't just read the rest of the thread, I'd probably wonder why we
> are talking about --broken at all. Maybe:
>
>   The --broken option similarly needs a working tree. But because the
>   current implementation calls an external diff-index to do the work,
>   we don't have to bother setting up the working tree in the
>   git-describe process.

This rewrite left me slightly in the dark since I had to infer that git-diff-index calls setup_work_tree() itself. Perhaps:

    ...an external diff-index to do the work, which itself calls
    setup_work_tree(), we don't have to bother...
But that's minor.
Jeff King· Jan 29, 2019, 22:35 UTC · re: Eric Sunshine · lore

Re: [PATCH v3 2/3] Setup working tree in describe

On Tue, Jan 29, 2019 at 03:53:40PM -0500, Eric Sunshine wrote:
Show 18 quoted lines
> > > The implementation of --broken uses diff-index which calls
> > > setup_work_tree() itself.
> >
> > If I hadn't just read the rest of the thread, I'd probably wonder why we
> > are talking about --broken at all. Maybe:
> >
> >   The --broken option similarly needs a working tree. But because the
> >   current implementation calls an external diff-index to do the work,
> >   we don't have to bother setting up the working tree in the
> >   git-describe process.
> 
> This rewrite left me slightly in the dark since I had to infer that
> git-diff-index calls setup_work_tree() itself. Perhaps:
> 
>     ...an external diff-index to do the work, which itself calls
>     setup_work_tree(), we don't have to bother...
> 
> But that's minor.

Yeah, my reasoning was that we handed off to diff-index, so if it doesn't work, then it has its own bug. ;) But I agree it is probably better to just be explicit.

-Peff
Sebastian Staudt· Jan 30, 2019, 10:31 UTC · re: Jeff King · lore

Re: [PATCH v3 2/3] Setup working tree in describe

Am Di., 29. Jan. 2019 um 23:35 Uhr schrieb Jeff King <peff@peff.net>:
Show 25 quoted lines
>
> On Tue, Jan 29, 2019 at 03:53:40PM -0500, Eric Sunshine wrote:
>
> > > > The implementation of --broken uses diff-index which calls
> > > > setup_work_tree() itself.
> > >
> > > If I hadn't just read the rest of the thread, I'd probably wonder why we
> > > are talking about --broken at all. Maybe:
> > >
> > >   The --broken option similarly needs a working tree. But because the
> > >   current implementation calls an external diff-index to do the work,
> > >   we don't have to bother setting up the working tree in the
> > >   git-describe process.
> >
> > This rewrite left me slightly in the dark since I had to infer that
> > git-diff-index calls setup_work_tree() itself. Perhaps:
> >
> >     ...an external diff-index to do the work, which itself calls
> >     setup_work_tree(), we don't have to bother...
> >
> > But that's minor.
>
> Yeah, my reasoning was that we handed off to diff-index, so if it
> doesn't work, then it has its own bug. ;) But I agree it is probably
> better to just be explicit.

Thanks for that valuable feedback. Is there some trailer like "Co-authored-commit-message-by:"? ;)

>
> -Peff
Jeff King· Jan 30, 2019, 12:44 UTC · re: Sebastian Staudt · lore

Re: [PATCH v3 2/3] Setup working tree in describe

On Wed, Jan 30, 2019 at 11:31:15AM +0100, Sebastian Staudt wrote:
Show 6 quoted lines
> > Yeah, my reasoning was that we handed off to diff-index, so if it
> > doesn't work, then it has its own bug. ;) But I agree it is probably
> > better to just be explicit.
> 
> Thanks for that valuable feedback.
> Is there some trailer like "Co-authored-commit-message-by:"? ;)

We often say "Helped-by", but I am OK with or without that in this case. To me, making suggestions like this is all just part of review. :)

-Peff
Sebastian Staudt· Jan 29, 2019, 05:18 UTC · re: Sebastian Staudt · lore

[PATCH v3 3/3] Add test for describe with a bare repository

This ensures that nothing breaks the basic functionality of describe for bare repositories. Please note that --broken and --dirty need a working tree.

Signed-off-by: Sebastian Staudt <koraktor@gmail.com>
---
 t/t6120-describe.sh | 5 +++++
 1 file changed, 5 insertions(+)
Show changes to t/t6120-describe.sh +5 −0
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index c863c4f600..f7539a2650 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -418,4 +418,9 @@ test_expect_success 'describe complains about missing object' '
 	test_must_fail git describe $ZERO_OID
 '
 
+test_expect_success 'describe works from outside repo using --git-dir' "
+  git clone --bare '$TRASH_DIRECTORY' '$TRASH_DIRECTORY/bare' &&
+  git --git-dir '$TRASH_DIRECTORY/bare' describe
+"
+
 test_done

-- 
2.20.1
Jeff King· Jan 29, 2019, 13:12 UTC · re: Sebastian Staudt · lore

Re: [PATCH v3 3/3] Add test for describe with a bare repository

On Tue, Jan 29, 2019 at 06:18:59AM +0100, Sebastian Staudt wrote:
> This ensures that nothing breaks the basic functionality of describe for
> bare repositories. Please note that --broken and --dirty need a working
> tree.
Makes sense.
> +test_expect_success 'describe works from outside repo using --git-dir' "
> +  git clone --bare '$TRASH_DIRECTORY' '$TRASH_DIRECTORY/bare' &&
> +  git --git-dir '$TRASH_DIRECTORY/bare' describe
> +"

What the test is doing seems sane, but the same quoting comments from the earlier patch apply.

-Peff
Sebastian Staudt· Jan 30, 2019, 10:23 UTC · re: Jeff King · lore

Re: [PATCH v3 3/3] Add test for describe with a bare repository

Am Di., 29. Jan. 2019 um 14:12 Uhr schrieb Jeff King <peff@peff.net>:
Show 17 quoted lines
>
> On Tue, Jan 29, 2019 at 06:18:59AM +0100, Sebastian Staudt wrote:
>
> > This ensures that nothing breaks the basic functionality of describe for
> > bare repositories. Please note that --broken and --dirty need a working
> > tree.
>
> Makes sense.
>
> > +test_expect_success 'describe works from outside repo using --git-dir' "
> > +  git clone --bare '$TRASH_DIRECTORY' '$TRASH_DIRECTORY/bare' &&
> > +  git --git-dir '$TRASH_DIRECTORY/bare' describe
> > +"
>
> What the test is doing seems sane, but the same quoting comments from
> the earlier patch apply.
>
Ok, thanks.
> -Peff
Jeff King· Jan 29, 2019, 13:00 UTC · re: Sebastian Staudt · lore

Re: [PATCH v3 1/3] Add tests for describe with --work-tree

On Tue, Jan 29, 2019 at 06:18:57AM +0100, Sebastian Staudt wrote:
Show 17 quoted lines
> The dirty ones are already passing, but just because describe is comparing
> with the wrong working tree.
> 
> Signed-off-by: Sebastian Staudt <koraktor@gmail.com>
> ---
>  t/t6120-describe.sh | 33 +++++++++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
> 
> diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
> index d639d94696..c863c4f600 100755
> --- a/t/t6120-describe.sh
> +++ b/t/t6120-describe.sh
> @@ -145,14 +145,38 @@ check_describe A-* HEAD
>  
>  check_describe "A-*[0-9a-f]" --dirty
>  
> +test_expect_success 'describe --dirty with --work-tree' "

This should be marked as test_expect_failure, I think, because it does not yet pass (and then flipped s/failure/success/ in the next patch).

> +	(
> +		cd '$TEST_DIRECTORY' &&
> +		git --git-dir '$TRASH_DIRECTORY/.git' --work-tree '$TRASH_DIRECTORY' describe --dirty >'$TRASH_DIRECTORY/out'
> +	) &&

The quoting you've done here is unusual for our test suite, and not quite as robust. You've put the whole test snippet into double-quotes, which means that $TRASH_DIRECTORY, etc, will be expanded before we eval the code.

By putting single-quotes around $TRASH_DIRECTORY, that makes it work when the path contains a space. But it would fail if somebody's filesystem path contains a single-quote.

The usual style is to put the whole snippet into single-quotes, and then double-quote as appropriate within it. Like:

  test_expect_failure 'describe --dirty with --work-tree' '
	(
		cd "$TEST_DIRECTORY" &&
		git --git-dir "$TRASH_DIRECTORY/.git" ...etc

Those variables will be expanded when test_expect_failure eval's the snippet.

> +	grep 'A-\d\+-g[0-9a-f]\+' '$TRASH_DIRECTORY/out'
Using "\d" isn't portable.

This regex is pretty broad. What are we checking here? If I understand the previous discussion, we just care that it doesn't have "dirty" in it, right? I don't think this regex does that, because it doesn't anchor the end of string.

If that's indeed what we're checking, then an easier check is perhaps:
  ! grep dirty ...

As a side note, you can also shorten your references to "out" by referring to it from the trash directory itself. I.e.:

  (
	cd "$TEST_DIRECTORY" &&
	git --git-dir="$TRASH_DIRECTORY/.git" --work-tree "$TRASH_DIRECTORY" \
	  describe --dirty
  ) >out &&
  ! grep dirty out
Same thing, but IMHO a little easier to read.
>  check_describe "A-*[0-9a-f]-dirty" --dirty
>  
> +test_expect_success 'describe --dirty with --work-tree' "
> [...]
Same comments apply to the other blocks you added.

Other than those mechanical things, though, what the tests are actually trying to do seems quite reasonable to me.

-Peff
Junio C Hamano· Jan 29, 2019, 17:47 UTC · re: Jeff King · lore

Re: [PATCH v3 1/3] Add tests for describe with --work-tree

Jeff King <peff@peff.net> writes:
Show 10 quoted lines
> The usual style is to put the whole snippet into single-quotes, and then
> double-quote as appropriate within it. Like:
>
>   test_expect_failure 'describe --dirty with --work-tree' '
> 	(
> 		cd "$TEST_DIRECTORY" &&
> 		git --git-dir "$TRASH_DIRECTORY/.git" ...etc
>
> Those variables will be expanded when test_expect_failure eval's the
> snippet.
Good.
>> +	grep 'A-\d\+-g[0-9a-f]\+' '$TRASH_DIRECTORY/out'
>
> Using "\d" isn't portable.

True, but not just \d. I think using \ before special characters to force an otherwise basic regular expression to be ERE (i.e. \+ at the end) is a GNUism.

Show 8 quoted lines
> This regex is pretty broad. What are we checking here? If I understand
> the previous discussion, we just care that it doesn't have "dirty" in
> it, right? I don't think this regex does that, because it doesn't anchor
> the end of string.
>
> If that's indeed what we're checking, then an easier check is perhaps:
>
>   ! grep dirty ...
Good.
Sebastian Staudt· Jan 30, 2019, 10:23 UTC · re: Junio C Hamano · lore

Re: [PATCH v3 1/3] Add tests for describe with --work-tree

Am Di., 29. Jan. 2019 um 18:47 Uhr schrieb Junio C Hamano <gitster@pobox.com>:
Show 15 quoted lines
>
> Jeff King <peff@peff.net> writes:
>
> > The usual style is to put the whole snippet into single-quotes, and then
> > double-quote as appropriate within it. Like:
> >
> >   test_expect_failure 'describe --dirty with --work-tree' '
> >       (
> >               cd "$TEST_DIRECTORY" &&
> >               git --git-dir "$TRASH_DIRECTORY/.git" ...etc
> >
> > Those variables will be expanded when test_expect_failure eval's the
> > snippet.
>
> Good.
Ok, thanks. I’ll change this in the next reroll.
Show 9 quoted lines
>
> >> +    grep 'A-\d\+-g[0-9a-f]\+' '$TRASH_DIRECTORY/out'
> >
> > Using "\d" isn't portable.
>
> True, but not just \d.  I think using \ before special characters to
> force an otherwise basic regular expression to be ERE (i.e. \+ at
> the end) is a GNUism.
>

I guess I’ll use the even broader but apparently more portable A-*[0-9a-f] then. It’s used in the other checks, so this should be OK?

Show 10 quoted lines
> > This regex is pretty broad. What are we checking here? If I understand
> > the previous discussion, we just care that it doesn't have "dirty" in
> > it, right? I don't think this regex does that, because it doesn't anchor
> > the end of string.
> >
> > If that's indeed what we're checking, then an easier check is perhaps:
> >
> >   ! grep dirty ...
>
> Good.

This was copied and pasted from the existing check for describe with a clean working tree. So this should be changed, too.

Jeff King· Jan 30, 2019, 12:43 UTC · re: Sebastian Staudt · lore

Re: [PATCH v3 1/3] Add tests for describe with --work-tree

On Wed, Jan 30, 2019 at 11:23:14AM +0100, Sebastian Staudt wrote:
Show 11 quoted lines
> > >> +    grep 'A-\d\+-g[0-9a-f]\+' '$TRASH_DIRECTORY/out'
> > >
> > > Using "\d" isn't portable.
> >
> > True, but not just \d.  I think using \ before special characters to
> > force an otherwise basic regular expression to be ERE (i.e. \+ at
> > the end) is a GNUism.
> >
> 
> I guess I’ll use the even broader but apparently more portable A-*[0-9a-f]
> then. It’s used in the other checks, so this should be OK?

Yeah, that is OK, as long as you use it with `case` like check_describe does. Because it's a glob and not a regex, you do not have to worry about the anchoring issue.

Or if you mean to do an anchored but more general regex like:
  ^A-.*[0-9a-f]$
that is OK, too.
Show 8 quoted lines
> > > If that's indeed what we're checking, then an easier check is perhaps:
> > >
> > >   ! grep dirty ...
> >
> > Good.
> 
> This was copied and pasted from the existing check for describe with a
> clean working tree. So this should be changed, too.

I do think that makes what we're checking more obvious, so I wouldn't mind seeing the other tests converted to use this. But it may be hard if they are relying on check_describe().

I'm OK with anything that works and is robust. :)
-Peff

← back to recent threads