From: Martin Langhoff <martin.langhoff@gmail.com>
To: Junio C Hamano <junkio@cox.net>
Cc: Ryan Anderson <ryan@michonline.com>, git@vger.kernel.org
Subject: Re: [PATCH 0/2] Update git-send-email-script with --compose
Date: Tue, 6 Sep 2005 08:06:50 +1200 [thread overview]
Message-ID: <46a038f90509051306212d4e93@mail.gmail.com> (raw)
In-Reply-To: <7vll2b4ake.fsf@assigned-by-dhcp.cox.net>
On 9/6/05, Junio C Hamano <junkio@cox.net> wrote:
> Ryan Anderson <ryan@michonline.com> writes:
> > 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
next prev parent reply other threads:[~2005-09-05 20:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-05 5:13 [PATCH 0/2] Update git-send-email-script with --compose Ryan Anderson
2005-09-05 5:13 ` [PATCH 1/2] Make git-send-email-script ignore some unnecessary options when operating in batch mode Ryan Anderson
2005-09-05 5:13 ` [PATCH 2/2] Update documentation of --compose to git-send-email-script.txt Ryan Anderson
2005-09-05 11:16 ` [PATCH 0/2] Update git-send-email-script with --compose Martin Langhoff
2005-09-05 15:37 ` Ryan Anderson
2005-09-05 18:46 ` Junio C Hamano
2005-09-05 20:06 ` Martin Langhoff [this message]
2005-09-05 20:38 ` Junio C Hamano
2005-09-05 20:45 ` Martin Langhoff
2005-09-05 21:10 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46a038f90509051306212d4e93@mail.gmail.com \
--to=martin.langhoff@gmail.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=ryan@michonline.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.