Re: [PATCH 0/2] Update git-send-email-script with --compose

On 9/6/05, Junio C Hamano [off-list ref] wrote:

Ryan Anderson [off-list ref] writes:

quoted

Sorry about that - I always export using git-format-patch using --mbox,
and those work nicely.  I'm a bit reluctant to do the [PATCH] fixup, but
I think I will:

Thanks Ryan for the clarification! I hadn't realized it would work
correctly with --mbox -- unfortunately it doesn't work very well in
the one-file-per-patch (legacy?) mode. Also, telling it _not_ to
prompt when it can guess it, is far better (a confirm y/n can still be
a good thing if you want to ensure the user gets a chance to review
the values guessed).

Martin, --mbox has the added benefit that it consistently
preserves the From: and Date: information even for your own
patches, because it implies --date and --author.  By default
without --author and --date these are not preserved from the
original commits for your own patches, primarily because
format-patch without --mbox was written for reorganizing and
reordering existing patches (i.e. export, concatenate some, edit
some hunks, and eventually feed it to applymbox to make commits;
you do not typically want to keep the original author date for
this kind of use).

Fair enough -- blame it on my primitive approach of only having 2
working repositories, and having some patches in them that I'm not
pushing upstream. Exporting to mbox would mean that I have to edit the
mbox file to remove the patches I don't intend to publish.

... and on my naive reading of git-send-email documentation -- it
doesn't mention mbox format at all, so I assumed it would expect one
patch per file.

Martin, is there a reason you do not want --mbox format
(e.g. format-patch --mbox spits out Subject: line undesirably
formatted while it does what you want without --mbox)?

Hmmm -- that I am too lazy to keep several heads or several repos, and
organize them to have a "tojunio" branch? So far I've been working on
one or two files (archimport) and customizing a couple of others with
strictly local changes (git-send-email for instance), so it didn't
make sense to formally segregate the heads. A simple review and manual
"cherrypicking" of the patches I wanted to send was enough.

cheers,


martin