On Mon, May 25, 2009 at 8:39 AM, Junio C Hamano <gitster@pobox.com> wrote:
quoted text
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> But then the name munge would not be descriptive of what the command
>> does. If git am is to be left untouched, I would rather then have
>> something like git import-patches that accepts patches in 'any'
>> format,...
>
> There is no need to introduce any new program, I think.

I'm not so sure about this, see below.

quoted text
> Nobody is against your teaching the "git am" callchain to accept things
> other than Berkeley mbox.  "git am" is "import-patches" in that sense
> already.

I thought as much 8-)

quoted text
> You can add a conditional (perhaps triggered by a "the patches are in this
> format" command line option) to "git am"

I'd rather have autodetection than command line options, at least as
long as it can be done reliably enough.

quoted text
> to alter the way it splits the
> input into individual pieces of e-mail, named 0001, 0002, 0003, ..., and
> leaves the total number of message in $dotest/last.
> Currently we call "git-mailsplit" to do all of that; your new conditional
> will take StGIT export, and instead of calling "git-mailsplit", read the
> series file and process individual patch files into 0001, 0002,... that
> are in proper mbox format (i.e. you would need to fix the "Subject: " less
> title line when you do this), and leave the total number of patches in
> $dotest/last file.

Hm. It does make sense to have mail conversion at 'mailsplit' time.
The preprocessing would (1) explode any series, if present (2) convert
the patch from whatever format they are in into mbox format (3) put
them in place. (1) is what my git am patch does, so what we need is
essentially (2). For efficiency we could assume that the user does not
pass patches of different formats to us, so we peek at the first patch
and treat all of them as that kind of patch.

I do suspect that patch format conversion _does_ require an additional
program, in the sense that not doing so would make the git-am script
grow, and I'm not sure it would be very efficient. Is core git C+sh
only or can we rely on some Perl stuff? It'd probably be more
appropriate for this kind of job.

quoted text
> With that change, the main loop that iterates 'while test "$this" -le
> "$last"' does not have to change, right?

Well, my proposed change git-munge | git-mailinfo would not be that
big of a change, but it does make sense to make the conversion early
on, as I mentioned above. It also makes it easier to debug the
conversion, as the result is kept in the dotest directory.

quoted text
> We could for example add RMAIL format support in the same way.

No idea what that is.

-- 
Giuseppe "Oblomov" Bilotta
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html