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: Abhijeet Sonar <abhijeet.nkt@gmail.com>,
	 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 v7] describe: refresh the index when 'broken' flag is used
Date: Wed, 03 Jul 2024 11:17:04 -0700	[thread overview]
Message-ID: <xmqq1q4acpcv.fsf@gitster.g> (raw)
In-Reply-To: <CAOLa=ZR-g4G0FaxnQjjkOST-zeRxBXXK1gpJ=P3xdbi_9eN_rg@mail.gmail.com> (Karthik Nayak's message of "Tue, 2 Jul 2024 10:13:30 +0000")

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

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Karthik Nayak <karthik.188@gmail.com> writes:
>>
>>> This explains for why 'broken' must use a subprocess, but there is
>>> nothing stopping 'dirty' from also using a subprocess, right? It
>>> currently uses an in-process index refresh but it _could_ be a
>>> subprocess too.
>>
>> Correct, except that it does not make sense to do any and all things
>> that you _could_ do.  So...
>
> Well, In this context, I think there is some merit though. There are two
> blocks of code `--broken` and `--dirty` one after the other which both
> need to refresh the index. With this patch, 'broken' will use a child
> process to do so while 'dirty' will use `refresh_index(...)`. To someone
> reading the code it would seem a bit confusing.

Yes, that much I very much agree.

> I agree there is no
> merit in using a child process in 'dirty' by itself.

Yes, that made me puzzled why you brought it up, as it was way too
oblique suggestion to ...

> But I also think we
> should leave a comment there for readers to understand the distinction.

... improve the "documentation" to help future developers who wonder
why the code are in the shape as it is.

In this particular case, I think it is borderline if the issue
warrants in-code comment or if it is a bit too much.  Describing the
same thing in the log message would probably be a valid alternative,
as "git blame" can lead those readers to the commit that introduced
the distinction (in other words, this one).

Thanks.

diff --git i/builtin/describe.c w/builtin/describe.c
index e936d2c19f..bc2ad60b35 100644
--- i/builtin/describe.c
+++ w/builtin/describe.c
@@ -648,6 +648,14 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
 
 	if (argc == 0) {
 		if (broken) {
+			/* 
+			 * Avoid doing these "update-index --refresh"
+			 * and "diff-index" operations in-process
+			 * (like how the code path for "--dirty"
+			 * without "--broken" does so below), as we
+			 * are told to prepare for a broken repository
+			 * where running these may lead to die().
+			 */
 			struct child_process cp = CHILD_PROCESS_INIT;
 
 			strvec_pushv(&cp.args, update_index_args);

  reply	other threads:[~2024-07-03 18:17 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
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 [this message]
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=xmqq1q4acpcv.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=abhijeet.nkt@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=karthik.188@gmail.com \
    --cc=newren@gmail.com \
    --cc=paul.millar@desy.de \
    --cc=peff@peff.net \
    --cc=phillip.wood123@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 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).