Re: [PATCH] mailsplit add option to include sanitized subject in filename

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

Jacob Keller <jacob.keller@gmail.com> writes:

>> > I originally wanted to avoid the need for an option, but git-am
>> > currently depends on the strict sequence number filenames.  It is
>> > unclear how difficult it would be to refactor git-am to work with
>> > names that include the extra subject data.

The change may be a bit involved but depending on where you decide
to stop, it may not be too bad.

What is your design goal of this topic?  IOW, what is the maximum
corrupted ordering of patches in a single mailbox do you want to
recover from?

The easiest and cleanest would be if you assume that the messages
are in scrambled order, but are all from the same series, correctly
numbered, without anything missing.  A mbox may have 8 patches from
a 8-patch series, with their subject lines having [1/8] to [8/8]
without duplicates or droppages, without any other message that does
not belong to the series.  If that is where you are willing to stop,
then you can still name the individual messages with just numbers
(but taken out of the subject line, not the order the input was
splitted into).  "am" does not have to even know or care what you
are doing in mailsplit in this case.

THe next level would be to still assume that you stop at the same
place (i.e. you do not support patches from multiple series in the
same mailbox), but use the number-santized-subject format.  This
would be a bit more involved, but I think all you need to update on
the "am" side is where the am_run() assigns the message file to the
local variable "mail".  You know the temporary directory where you
told "mailsplit" to create these individual messages, so you should
be able to "opendir/readdir/closedir" and create a list of numbered
files in the directory very early in "git am".  Knowing msgnum(state)
at that point in the loop, it should be trivial to change the code
that currently assumes the 4-th file is named "0004" to check for
the file whose name begins with "0004-".

I personally am not at all interested in doing that myself, because
I do not see a reasonable way to lift the limitation of allowing a
mailbox holding patches from only one series, and if we assume that
a tool (i.e. "am" driving "mailsplit" in the new mode) with such a
limitation is still useful, the source of such a scrambled mailbox
must be quite a narrow and common one.  At that point, I suspect
that fixing the scrambling at that narrow and common source (e.g.
your "t.mbox.gz from public inbox server that cannot be told to sort
the messages in any order other than the arrival timestamp") would
be a much better use of our engineering resource.