Replies: 3 comments 3 replies
-
I've used "stg mail" since the beginning, and have never had to use "git send-email" so it's difficult for me to answer the questions you pose. However, there are some ideas I've had for "stg mail" for a while.
For the kernel e-mail workflow, I might send the same set of patches again after addressing review comments. That can happen again and again, and each of these is marked with a "vN". It would be great if the mail tool could handle post versioning naturally:
|
Beta Was this translation helpful? Give feedback.
-
I use git send-email almost exclusively these days. One of the reasons is that I find it easier to do a git format-patch --cover and edit the cover letter, copy stuff from the previous version of the series, add changelog before sending it with git send-email. What would be nice is if stgit can maintain a cover letter for a branch that I can edit (add changelog etc.) as I work on a series of patches. Maybe a 'stg branch --edit-cover' option (we have stg branch --description but this one only stores a text in .git/config). This way I won't need to do a git format-patch, vim 0000-cover-letter, git send-email. Personally I'd offload all the mail delivery part (authentication, even aliases) to git and keep stg mail as a light wrapper that exports the patches and cover letter in a temporary directory before invoking git send-email. |
Beta Was this translation helpful? Give feedback.
-
I've just made a v2.0.0-alpha.2 release that includes two new commands: I have not yet addressed associating a cover letter (or cover letter template) with the branch. I'd really like to hear from folks more tuned-into email-based workflows on exactly what cover letter capabilities should look like. For the time being, the capability is the same as what git provides, i.e. Also not addressed is automating the series version (a.k.a. reroll count). The more I thought about this one, the less confident I felt about being able to automatically determine when the reroll count should increment. At format-time? At send-time? Resend the same version (perhaps to different recipients) is a thing, right? Anyway, I'm not confident on a path forward for this feature. Suggestions welcome. N.B. I don't intend to hold-up the 2.0.0 release for additional email features. My hope is that what's there now is sufficient for the 2.0.0 release. |
Beta Was this translation helpful? Give feedback.
-
See #185 for context.
For StGit 2.0, a big remaining open question is what to do about
stg mail
?I'd like to either retire it entirely or replace it with a command that is more of a thin facade for
git send-email
. But I've never been a user ofstg mail
, so I remain fuzzy on the value proposition it offers versus plaingit send-email
. So I'm looking for StGit users that use email-based workflows to chime-in. I'm interested in both what people value aboutstg mail
as well as why some of you bypassstg mail
and usegit send-email
instead?Some food for thought:
stg mail p0..pN
offer vis-a-visgit send-email $(stg id p0)..($stg id pN)
?stg mail
only provides a subset of the options and capabilities ofgit send-email
/git format-patch
, with few capabilities that differ.stg mail
's cover letter strategy that is different/better thangit send-email
?git send-email --cover-from-description
(orformat.coverFromDescription
in the config) seems to provide a similar capability. Is it good enough?git format-patch
?Regarding the idea of "a thin facade for
git send-email
", I'm thinking about astg send-email
command that maps patchname/patchrange arguments to the revision-range arguments needed bygit send-email
, and then callsgit send-email
, transparently passing-through all other options. Would this be a good solution for emailing StGit patches?Beta Was this translation helpful? Give feedback.
All reactions