Re: [PATCH v2 0/2] git-send-email: Message-ID caching
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 22, 2013, 00:20 UTC
- Message-ID
- <xmqqbo4qshiv.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <1377111862-13199-1-git-send-email-rv@rasmusvillemoes.dk>
Rasmus Villemoes <rv@rasmusvillemoes.dk> writes:
Show 15 quoted lines
>> Rasmus Villemoes <rv@rasmusvillemoes.dk> writes:
>>> my %config_path_settings = (
>>> @@ -311,6 +314,7 @@ my $rc = GetOptions("h" => \$help,
>>> "8bit-encoding=s" => \$auto_8bit_encoding,
>>> "compose-encoding=s" => \$compose_encoding,
>>> "force" => \$force,
>>> + "msgid-cache-file=s" => \$msgid_cache_file,
>>> );
>>
>> Is there a standard, recommended location we suggest users to store
>> this?
>
> I don't know. It is obviously a local, per-repository, thing. I don't
> know enough about git's internals to know if something breaks if one
> puts it in .git (say, ".git/msgid.cache").I think $GIT_DIR is OK, when we _know_ we are in a Git controlled directory. "git send-email" can however be invoked in a random directory that is _not_ a Git controlled directory, though.
In any case, if we were to store it inside $GIT_DIR, I'd prefer to have "send-email" somewhere in the name of the file, as there are other Git programs that deal with things that have "msgid" (notably, "am") that will not have anything to do with this file.
> If storing it under .git is possible, one could consider making the
> option a boolean ('msgid-use-cache' ?) and always use
> ".git/msgid.cache".Another possibility is to have it in the output directory specified via the "format-patch -o $dir" option. When you are rerolling a series multiple times, you will only look at the message ID from the previous round; you do not even need to look at old messages in an unrelated topic.
I could imagine that
git send-email $dir/0*.txt
can notice that these input files are all in the same $dir directory, check to see if $dir/message-id file exists, read it to offer it as the suggested initial-reply-to. Similarly, when sending the _first_ message in such an invocation, it can just write the generated message-id to that file. Then we need no choices. It is sufficient to just keep a single message-id of the first message in the previous round and offer it as a possible initial-reply-to in a Yes/No question.
Just a random thought.