From: Junio C Hamano <gitster@pobox.com>
To: Aditya Garg <gargaditya08@live.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
Eric Sunshine <sunshine@sunshineco.com>,
Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>,
Ben Knoble <ben.knoble@gmail.com>,
brian m carlson <sandals@crustytoothpaste.net>
Subject: Re: [PATCH] imap-send: add option to mark sent messages as read or unread
Date: Wed, 23 Jul 2025 10:55:38 -0700 [thread overview]
Message-ID: <xmqqtt32n65h.fsf@gitster.g> (raw)
In-Reply-To: <PN3PR01MB95970E44092A27F47AF25CF8B85FA@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM> (Aditya Garg's message of "Wed, 23 Jul 2025 17:33:36 +0000")
Aditya Garg <gargaditya08@live.com> writes:
>> On 23 Jul 2025, at 10:55 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Aditya Garg <gargaditya08@live.com> writes:
>>
>>> +imap.markAsRead::
>>> + Choose whether to mark the sent message as read or not.
>>
>> Is this something user typically want to use a single setting,
>> or would it often be per invocation? Especially with the new
>> invoker in send-email, wouldn't it become more like "if I use
>> imap-send to stuff things in my outgoing folder, they shouldn't be
>> marked as read, but fcc copies send-email stuffs via imap-send
>> should be marked as read" or something like that?
>
> So whenever the user changes the folder, he can change this option too?
I am not sure what you mean. If it is primarily per invocation, we
do not want a new configuration variable. A new feature should be
introduced behind a command line option (disabled by default) first,
and then if it proves useful enough to wide audience, a configuration
is added for enhanced usability. Adding a new configuration variable
at the same time an option is introduced smelled more like a spinal
reflection than a well thought out design.
next prev parent reply other threads:[~2025-07-23 17:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-23 12:29 [PATCH] imap-send: add option to mark sent messages as read or unread Aditya Garg
2025-07-23 17:25 ` Junio C Hamano
2025-07-23 17:33 ` Aditya Garg
2025-07-23 17:35 ` Aditya Garg
2025-07-23 17:56 ` Junio C Hamano
2025-07-23 18:00 ` Aditya Garg
2025-07-23 17:55 ` Junio C Hamano [this message]
2025-07-23 17:52 ` Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2025-07-23 15:45 Aditya Garg
2025-07-23 17:46 ` Junio C Hamano
2025-07-23 17:49 ` Aditya Garg
2025-07-23 17:55 Aditya Garg
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=xmqqtt32n65h.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ben.knoble@gmail.com \
--cc=gargaditya08@live.com \
--cc=git@vger.kernel.org \
--cc=kristofferhaugsbakk@fastmail.com \
--cc=sandals@crustytoothpaste.net \
--cc=sunshine@sunshineco.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.