Re: [PATCH 0/2] StGit patch series import

From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Date: May 25, 2009, 07:19 UTC
Message-ID: <cb7bb73a0905250019y12e3747brff3c0b6a6523c41a@mail.gmail.com>
In-Reply-To: <7vocthy9df.fsf@alter.siamese.dyndns.org>

On Mon, May 25, 2009 at 8:39 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 8 quoted lines

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

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

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

Show 9 quoted lines

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

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

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

No idea what that is.

-- 
Giuseppe "Oblomov" Bilotta