Git development
 help / color / mirror / Atom feed
From: Siddharth Asthana <siddharthasthana31@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, karthik.188@gmail.com,
	christian.couder@gmail.com, ps@pks.im, toon@iotcl.com,
	jn.avila@free.fr
Subject: Re: [PATCH v4 1/1] cat-file: add mailmap subcommand to --batch-command
Date: Thu, 16 Apr 2026 08:38:36 +0530	[thread overview]
Message-ID: <3e07118b-f98a-4bf2-ac7a-39c1f114a651@gmail.com> (raw)
In-Reply-To: <xmqqa4v46ptu.fsf@gitster.g>



On 15/04/26 23:58, Junio C Hamano wrote:
> Siddharth Asthana <siddharthasthana31@gmail.com> writes:
> 
>> diff --git a/Documentation/git-cat-file.adoc b/Documentation/git-cat-file.adoc
>> index c139f55a16..0f499c9d1b 100644
>> --- a/Documentation/git-cat-file.adoc
>> +++ b/Documentation/git-cat-file.adoc
>> @@ -174,6 +174,18 @@ flush::
>>   	since the beginning or since the last flush was issued. When `--buffer`
>>   	is used, no output will come until a `flush` is issued. When `--buffer`
>>   	is not used, commands are flushed each time without issuing `flush`.
>> +
>> +`mailmap (<bool>)`::
>> +	Enable or disable mailmap for subsequent commands. The `<bool>`
>> +	argument accepts the same boolean values as linkgit:git-config[1].
>> +	Possible effects are:
>> ++
>> +`true`;;
>> +	Mailmap data is loaded on first use and kept in memory until the
>> +	process exits. Passing `true` again does not reload the data.
>> +`false`;;
>> +	Mailmap replacements are disabled for subsequent commands, but data
>> +	already loaded stays in memory.
>>   --
>>   +
> 
> While the above may not be telling any lies, I think the focus of
> the explanation is placed on a wrong thing.  What primarily matters
> to end-users is that toggling 'mailmap' to true makes the mailmap
> applied to identities before they appear in the output and false
> makes the identities output without modification.  The fact that you


Make sense, the sub-list was over-explaining implementation details that 
users don't need to care about.


> read the mailmap data only once and keep it around even when
> toggling the feature off, just in case the feature gets turned on
> again, is an implementation detail that is of much lessor interest
> to end users, no?
> 
> Perhaps delete everything from "Possible effects are" and replace it
> with a brief explanation, e.g.,
> 
> `mailmap (<bool>)`::
> 	Enable or disable mailmap for subsequent commands. The `<bool>`
> 	argument accepts the same boolean values as linkgit:git-config[1].
> 	The mailmap data is read upon the first use and only once,
> 	even after the `mailmap` command is given multiple times to
> 	toggle it off and then on back again.
> 
> would be sufficient (I would omit "even after ..." part, if I were
> writing it).  What is more important than the optimization aspect of



Agreed, I wend with the shorter version without the "even after" part.


> this implementation detail to end users is that we do not re-read,
> so if you update the file while you are running "cat-file --batch",
> even giving 'mailmap off; mailmap on' would not cause it to re-read
> the updated data, and "upon the first use and only once" should be
> sufficient to understand that.
> 
> The implementation looks great.  I do not recall how good the tests
> were but this round does not change anything there since the
> previous iteration.


Thnaks! I will send v5 with just this doc change.

Siddharth



  reply	other threads:[~2026-04-16  3:08 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-28 20:36 [PATCH v1 1/1] cat-file: add use-mailmap/no-use-mailmap to --batch-command Siddharth Asthana
2026-03-29  0:50 ` Junio C Hamano
2026-03-29  7:25   ` Siddharth Asthana
2026-03-29 20:55     ` Junio C Hamano
2026-03-29  8:28 ` [PATCH v2 0/1] cat-file: add mailmap subcommand " Siddharth Asthana
2026-03-29  8:28   ` [PATCH v2 1/1] " Siddharth Asthana
2026-03-30  2:12     ` Junio C Hamano
2026-03-31  1:40       ` Siddharth Asthana
2026-03-31  3:41         ` Junio C Hamano
2026-03-30  9:44     ` Karthik Nayak
2026-03-31  1:42       ` Siddharth Asthana
2026-03-30 10:37     ` Patrick Steinhardt
2026-03-30 14:53       ` Junio C Hamano
2026-03-31  1:43       ` Siddharth Asthana
2026-03-31 17:11     ` Jean-Noël AVILA
2026-03-31 17:49       ` Junio C Hamano
2026-04-01 10:11         ` Jean-Noël Avila
2026-03-31 12:11   ` [PATCH v3 0/1] " Siddharth Asthana
2026-03-31 12:11     ` [PATCH v3 1/1] " Siddharth Asthana
2026-03-31 19:21       ` Junio C Hamano
2026-04-10 18:29         ` Junio C Hamano
2026-04-15 15:09     ` [PATCH v4 0/1] " Siddharth Asthana
2026-04-15 15:09       ` [PATCH v4 1/1] " Siddharth Asthana
2026-04-15 18:28         ` Junio C Hamano
2026-04-16  3:08           ` Siddharth Asthana [this message]
2026-04-16  3:32       ` [PATCH v5 0/1] " Siddharth Asthana
2026-04-16  3:32         ` [PATCH v5 1/1] " Siddharth Asthana

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=3e07118b-f98a-4bf2-ac7a-39c1f114a651@gmail.com \
    --to=siddharthasthana31@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jn.avila@free.fr \
    --cc=karthik.188@gmail.com \
    --cc=ps@pks.im \
    --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