Re: [PATCH v2] contrib: git-cpcover: copy cover letter
- From
- Michael S. Tsirkin <mst@redhat.com>
- Date
- Dec 9, 2019, 15:49 UTC
- Message-ID
- <20191209102727-mutt-send-email-mst@kernel.org>
- In-Reply-To
- <20191204044449.GB226135@google.com>
On Tue, Dec 03, 2019 at 08:44:49PM -0800, Jonathan Nieder wrote:
Show 24 quoted lines
> Hi, > > Michael S. Tsirkin wrote: > > > My flow looks like this: > > 1. git format-patch -v<n> --cover-letter <params> -o <dir> > > 2. vi <dir>/v<n-1>-0000-cover-letter.patch <dir>/v<n>-0000-cover-letter.patch > > > > copy subject and blurb, avoiding patchset stats > > > > 3. add changelog update blurb as appropriate > > > > 4. git send-email <dir>/v<n>-* > > > > The following perl script automates step 2 above. > > Neat. I wonder, should "git format-patch" learn an option for this? > E.g. > > git format-patch -v<n> --cover-letter \ > --last-cover-letter=<dir>/v<n-1>-0000-cover-letter.patch \ > -o <dir> > > What would your ideal interface for this flow look like?
I use it in several ways - new version - generate a new version from previous one git format-patch -o patches/series .... git cpcover patches/series/saved-cover-letter.patch patches/series/vN-cover-letter.patch
So ideally it would automatically pick up vN-1 cover letter if it's there.
- update - I generate patches but don't post yet. write a cover letter with e.g. an explanation, decide to make some changes before posting. Then: cp patches/series/vN-cover-letter.patch patches/series/saved-cover-letter.patch git format-patch -o patches/series .... git cpcover patches/series/saved-cover-letter.patch patches/series/vN-cover-letter.patch
So ideally if cover letter already exists, ask whether to copy it. or at least whether it's ok to over-write it...
- series history
I start with a non-versioned cover letter,
and maintain it in a directory:
cp patches/series/0000-cover-letter.patch patches/series/cover-letter.patch
This is where
I then put notes about design changes, list questions
to be answered, add people who contributed
to the discussion and should be Cc'd on new versions
Then each time I do
git format-patch -o patches/series ....
git cpcover patches/series/cover-letter.patch patches/series/vN-cover-letter.patch
- public-inbox
get series from public inbox (from someone else
or myself) and work on itIdeally if cover-letter without a version exists, pick it up.
During all of this, it's important to pick up description, subject, to/cc.
Also one thing I need to remember to do is update changelog.
If there's a standard way to document version changes, ideally it will be possible to check whether latest version changes have been documented, and print a reminder if not.
Show 11 quoted lines
> [...] > > Any feedback on this? Interest in taking this into contrib/ for now? > > I don't know what Junio's preferences are for new contrib/ > contributions, but I kind of like it. If putting it in contrib/, my > main advice would be to put it in a subdirectory there with a README. > That way, we have a good place to document what it was replaced by > once it has graduated to a standard format-patch feature. > > Thanks and hope that helps, > Jonathan
OK so contrib/format-patch/ ?
-- MST