public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox•com>
To: Abhijeet Sonar <abhijeet.nkt@gmail•com>
Cc: git@vger•kernel.org,  Paul Millar <paul.millar@desy•de>,
	 Phillip Wood <phillip.wood123@gmail•com>,
	 Elijah Newren <newren@gmail•com>,  Jeff King <peff@peff•net>
Subject: Re: [PATCH v5] describe: refresh the index when 'broken' flag is used
Date: Wed, 26 Jun 2024 11:31:25 -0700	[thread overview]
Message-ID: <xmqqpls3zhc2.fsf@gitster.g> (raw)
In-Reply-To: <20240626065223.28154-1-abhijeet.nkt@gmail.com> (Abhijeet Sonar's message of "Wed, 26 Jun 2024 12:22:11 +0530")

Abhijeet Sonar <abhijeet.nkt@gmail•com> writes:

> When describe is run with 'dirty' flag, we refresh the index
> to make sure it is in sync with the filesystem before
> determining if the working tree is dirty.  However, this is
> not done for the codepath where the 'broken' flag is used.
>
> This causes `git describe --broken --dirty` to false
> positively report the worktree being dirty if a file has
> different stat info than what is recorded in the index.
> Running `git update-index -q --refresh` to refresh the index
> before running diff-index fixes the problem.
>
> Also add tests to deliberately update stat info of a
> file before running describe to verify it behaves correctly.
>
> Reported-by: Paul Millar <paul.millar@desy•de>
> Suggested-by: Junio C Hamano <gitster@pobox•com>
> Helped-by: Junio C Hamano <gitster@pobox•com>
> Helped-by: Phillip Wood <phillip.wood123@gmail•com>
> Signed-off-by: Abhijeet Sonar <abhijeet.nkt@gmail•com>
> ---

As I screwed up with the suggestion to do child_process_clear()
after a failed run_command(), let me fix that up.  A suggested
change that can be squashed into this patch is attached at the end.

 * (style) a blank line between a block of variable declarations and
   the first statement;

 * run_command(&cp) cleans cp so no need for separate
   child_process_clear(&cp);

 * but child_process_init(&cp) is needed, just as 4d0984be (fsck: do
   not reuse child_process structs, 2018-11-12) explains, before
   reusing the structure for a separate call.

 * instead of "replace with a different file" which relies on having
   a working inum, use "test-tool chmtime" to reliably force dirty
   mtime.

 * everybody else compares "actual" against "expect", not
   "expected".  imitate them.

 * test "--dirty" and "--dirty --broken" separately in two separate
   tests.

Thanks.


 builtin/describe.c  |  5 +++--
 t/t6120-describe.sh | 28 ++++++++++++++++++++--------
 2 files changed, 23 insertions(+), 10 deletions(-)

diff --git c/builtin/describe.c w/builtin/describe.c
index a58f6134f0..e936d2c19f 100644
--- c/builtin/describe.c
+++ w/builtin/describe.c
@@ -649,13 +649,14 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
 	if (argc == 0) {
 		if (broken) {
 			struct child_process cp = CHILD_PROCESS_INIT;
+
 			strvec_pushv(&cp.args, update_index_args);
 			cp.git_cmd = 1;
 			cp.no_stdin = 1;
 			cp.no_stdout = 1;
-			if (run_command(&cp))
-				child_process_clear(&cp);
+			run_command(&cp);
 
+			child_process_init(&cp);
 			strvec_pushv(&cp.args, diff_index_args);
 			cp.git_cmd = 1;
 			cp.no_stdin = 1;
diff --git c/t/t6120-describe.sh w/t/t6120-describe.sh
index 6c396e7abc..79e0f19deb 100755
--- c/t/t6120-describe.sh
+++ w/t/t6120-describe.sh
@@ -672,6 +672,7 @@ test_expect_success 'setup misleading taggerdates' '
 check_describe newer-tag-older-commit~1 --contains unique-file~2
 
 test_expect_success 'describe --dirty with a file with changed stat' '
+	test_when_finished "rm -fr stat-dirty" &&
 	git init stat-dirty &&
 	(
 		cd stat-dirty &&
@@ -680,18 +681,29 @@ test_expect_success 'describe --dirty with a file with changed stat' '
 		git add file &&
 		git commit -m A &&
 		git tag A -a -m A &&
+		echo "A" >expect &&
 
-		cat file >file.new &&
-		mv file.new file &&
+		test-tool chmtime -10 file &&
 		git describe --dirty >actual &&
-		echo "A" >expected &&
-		test_cmp expected actual &&
+		test_cmp expect actual
+	)
+'
+
+test_expect_success 'describe --broken --dirty with a file with changed stat' '
+	test_when_finished "rm -fr stat-dirty" &&
+	git init stat-dirty &&
+	(
+		cd stat-dirty &&
 
-		cat file >file.new &&
-		mv file.new file &&
+		echo A >file &&
+		git add file &&
+		git commit -m A &&
+		git tag A -a -m A &&
+		echo "A" >expect &&
+
+		test-tool chmtime -10 file &&
 		git describe --dirty --broken >actual &&
-		echo "A" >expected &&
-		test_cmp expected actual
+		test_cmp expect actual
 	)
 '
 

  parent reply	other threads:[~2024-06-26 18:31 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-25 13:35 [PATCH v3] describe: refresh the index when 'broken' flag is used Abhijeet Sonar
2024-06-25 15:59 ` Junio C Hamano
2024-06-25 16:05   ` Junio C Hamano
2024-06-26 11:16     ` Karthik Nayak
2024-06-26  6:11   ` Abhijeet Sonar
2024-06-26  6:37   ` [PATCH v4] " Abhijeet Sonar
2024-06-26  6:50     ` Abhijeet Sonar
2024-06-26  6:52   ` [PATCH v5] " Abhijeet Sonar
2024-06-26 11:30     ` Karthik Nayak
2024-06-26 12:06       ` Abhijeet Sonar
2024-06-26 15:34         ` Re* " Junio C Hamano
2024-06-26 16:17           ` Junio C Hamano
2024-06-26 17:29             ` Abhijeet Sonar
2024-06-26 17:35               ` Junio C Hamano
2024-06-26 17:45                 ` Junio C Hamano
2024-06-26 18:07                 ` Abhijeet Sonar
2024-06-26 18:49                   ` Junio C Hamano
2024-06-26 20:34                     ` Jeff King
2024-06-27  0:33                       ` Jeff King
2024-06-26 21:23                     ` Karthik Nayak
2024-06-26 14:59       ` Junio C Hamano
2024-06-26 18:31     ` Junio C Hamano [this message]
2024-06-26 19:08       ` [PATCH v7] " Abhijeet Sonar
2024-06-26 19:25         ` Abhijeet Sonar
2024-06-27  6:01           ` Abhijeet Sonar
2024-06-27 15:47           ` Junio C Hamano
2024-06-27 17:33             ` Abhijeet Sonar
2024-06-30 16:12             ` Karthik Nayak
2024-07-01 19:06               ` Junio C Hamano
2024-07-02 10:13                 ` Karthik Nayak
2024-07-03 18:17                   ` Junio C Hamano
2024-07-03 20:41                     ` 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=xmqqpls3zhc2.fsf@gitster.g \
    --to=gitster@pobox$(echo .)com \
    --cc=abhijeet.nkt@gmail$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=newren@gmail$(echo .)com \
    --cc=paul.millar@desy$(echo .)de \
    --cc=peff@peff$(echo .)net \
    --cc=phillip.wood123@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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