It would be convenient to have per branch cover letters that are
stored by stg and get automatically applied when a patch set is
mailed. Use 'stg edit' to alter them. The first time you email a
series you would get an editor to write the cover letter if you hadn't
already done it. You could track the "to=" this way also.
Another useful feature would be a config option that says something
like "prompt for new version" when mailed. Now each time you mail the
series it throws you into the cover page editor with an incremented
patch version. You can just quit out of the editor if you don't want
to increment the version.
I didn't know I wanted features like this until I made a patch that
has gone through 25 versions.
--
Jon Smirl
jonsmirl@gmail.com
On 2008-01-25 09:57:50 -0500, Jon Smirl wrote:
It would be convenient to have per branch cover letters that are
stored by stg and get automatically applied when a patch set is
mailed. Use 'stg edit' to alter them. The first time you email a
series you would get an editor to write the cover letter if you
hadn't already done it. You could track the "to=" this way also.
I don't think we need to get quite that fancy. Wouldn't it suffice to
have a --cover-file=<filename> option to stg mail, and if both
--cover-file and --edit-cover were given, update that file with new
diffstat etc?
And per-branch config options if you want to set these permanently, of
course.
Another useful feature would be a config option that says something
like "prompt for new version" when mailed. Now each time you mail
the series it throws you into the cover page editor with an
incremented patch version. You can just quit out of the editor if
you don't want to increment the version.
Patches without cover letters can also have versions, so I don't think
associating versions with cover letters is a splendid idea, but I get
your point.
I guess a solution much like the one for cover letters would work
here. A separate file, and command-line and config options to point to
it.
I didn't know I wanted features like this until I made a patch that
has gone through 25 versions.
Your feedback is much appreciated. Keep at it!
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
On 1/25/08, Karl Hasselström [off-list ref] wrote:
On 2008-01-25 09:57:50 -0500, Jon Smirl wrote:
quoted
It would be convenient to have per branch cover letters that are
stored by stg and get automatically applied when a patch set is
mailed. Use 'stg edit' to alter them. The first time you email a
series you would get an editor to write the cover letter if you
hadn't already done it. You could track the "to=" this way also.
I don't think we need to get quite that fancy. Wouldn't it suffice to
have a --cover-file=<filename> option to stg mail, and if both
--cover-file and --edit-cover were given, update that file with new
diffstat etc?
I have five patch sets I'm currently juggling. It would be a lot more
convenient if stg remembered which cover letter went with the patch
set, the recipients for the mail and the current patch version/prefix.
In my tree each patch set is in it's own branch.
I can edit the config file to change these if need, I don't need a
fancy editor interface.
And per-branch config options if you want to set these permanently, of
course.
quoted
Another useful feature would be a config option that says something
like "prompt for new version" when mailed. Now each time you mail
the series it throws you into the cover page editor with an
incremented patch version. You can just quit out of the editor if
you don't want to increment the version.
Patches without cover letters can also have versions, so I don't think
associating versions with cover letters is a splendid idea, but I get
your point.
I guess a solution much like the one for cover letters would work
here. A separate file, and command-line and config options to point to
it.
quoted
I didn't know I wanted features like this until I made a patch that
has gone through 25 versions.
Your feedback is much appreciated. Keep at it!
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
--
Jon Smirl
jonsmirl@gmail.com