Re: [PATCH v2 0/2] git-send-email: Message-ID caching

[Junio C Hamano <gitster@pobox.com>]

Rasmus Villemoes <rv@rasmusvillemoes.dk> writes:

>> 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.