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

Ryan Anderson [off-list ref] writes:

On Mon, Sep 05, 2005 at 11:16:57PM +1200, Martin Langhoff wrote:

quoted

 - reads "subject" from the first line of STDIN or file. If the line
doesn't start with [PATCH it provides the [PATCH] prefix. I found it
really confusing that it wants to get 'from' in the first line...
that's not what git-format-patch produces!

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:

	1. Detect [PATCH] or [PATCH [0-9]+/[0-9]+] (Sorry for the horrid
	fake-regexp)
	2. Provide a --no-fixup-subject to turn that off.

(TODO #2)

To be consistent with the other tools in tools/ directory, the
above is probably 's/^/[PATCH] / unless (/^\[PATCH/])'

In this case, remember that this was an attempt to help users patch bomb
lists, getting all the subtle details correct.  The prompting is there
to help get the subtle details correct!

You could error out without asking if that is what is happening.

Well, I'm not.  Try "git format-patch --mbox -o patchdir origin" and see
if that works better for you.

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

I do apologize for not realizing that the default git format-patch
output doesn't match what git send-email script expects the "legacy"
mode - I'll sort that out one way or another as well. (TODO #3)

I do apologize for not really saying what --mbox does and what
the format-patch output without --mbox is meant for.

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

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