Re: [RFC] series headers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 10, 2007 at 02:56:48PM +0100, Johannes Schindelin wrote:
> And what is so wrong with
> 
> [insert before format-patch] $EDITOR my-cover-letter.txt
> 
> [replace $EDITOR 0000-cover-letter.txt] $EDITOR my-cover-letter.txt 
> 	0000-cover-letter.patch
> 
> and paste the changed text?

Nothing is *wrong* with it per-se, but if you have multiple things
that you are working on at the same-time, you might not want to keep
0000-cover-letter.patch in your working directory.  

The simplest place to put it is in .git/patches/<branch> while I'm
working with it using guilt (or the equivalent place in stgit), and if
you include it in the series file then it becomes easier to hack it so
that git-format-patches will create the cover letter for you.  (And
ideally, you would be able to use guilt to edit the cover letter using
"guilt header -e cover-letter" but that feature hasn't been added yet;
should be simple, though.)

Basically, the issue is of handling the cover letter as a first-class
object, as opposed to something whic his manually handled via
cut-and-paste.  A lot of the tools are actually there already if you
are using tools like guilt and stgit.  So it's basically making a
particular workflow a bit more optimized, that's all.  

There certainly is nothing *wrong* with manual maintenance of the
cover-letter file plus cut-and-paste when you want to update it.  Just
as there's nothing *wrong* with using git-write-tree instead of
git-commit.  Just a question of which is more convenient and less
error prone.  :-)

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux