Hi everyone,
first of all thank you for your timely and valuable feedback!
The idea of having an empty commit to store the cover letter sounds
really good to me, because of all the advantages you have already listed.
Indeed, the fact that it's an empty commit could be in itself the
indicator for a cover letter, with no extra markers needed.
I would also add the Cc: tags to that cover letter itself, along with
changelog information (i.e. changes wrt to the previous patch series
version, when it is more convenient to document that on a global basis
within the cover letter).
As for the per-patch changelog, it just occurred to me that adding a
"---" line in the commit message already does the trick.
Whatever follows that line is stored within the commit message and
spurted out by git-format-patch, but not applied by git-am.
Perhaps that was so obvious and it is so common practice that no one
ever cared to point it out to me. :-)
Adding some kind of "Patch-version: <v>" tag to the cover-letter would
just complete the picture (so that we get a [PATCH v 00/xx] subject prefix).
BTW, is there a way to duplicate a branch managed by stgit?
So that whenever I need to rework something, I can still keep the old
history around?
I was thinking of some:
NUM=`stg series | wc -l`; git checkout -b <new>; stg uncommit -n $NUM
but perhaps I'm completely off track here.
Thanks a lot again guys!
Gerlando
On 07/04/2013 07:05 AM, Karl Wiberg wrote:
On Thu, Jul 4, 2013 at 2:47 AM, Waskiewicz Jr, Peter P
<[email protected]> wrote:
On Thu, 2013-07-04 at 02:24 +0200, Karl Wiberg wrote:
Several other parts of StGit would need to be taught to give the
cover letter patches special treatment as well. I admit I haven't
thought it through extensively, but I think it wouldn't be that
hard to do.
I think this is the piece that I came to in my mind initially that
would need the work. But just some thought on it, how about this.
Add a new flag to stg new, something like:
$ stg new --cover <name>
That would create the new patch in the stgit refs, with whatever
header tags to flag it as a "special" patch. That way if you wanted
to come back later to add a cover letter, pop everything, add the
new patch, then push everything.
I actually don't think this would be a heavy lift at all.
Yes, that's precisely the sort of thing I had in mind.
Of course, one could consider alternative solutions that look the
same in the StGit UI, but don't actually create the empty commits,
storing their data elsewhere instead. However, the empty-commits
solution has the advantage that even tools that haven't been
taught to understand it (such as gitk) can see and manipulate the
cover letters in a useful fashion.
Wouldn't gitk need the patches to be in the git log to see them, not
just the stgit refs? If it does, I'm not sure we'd want to do that.
My primary suggestion is to have the empty cover letter commits in the
main branch ("master", say), along with the commits that represent
StGit patches. That way, they'd be visible with a plain
$ gitk
The alternative would be to store the data as files in the metadata
branch ("master.stgit", in this example), alongside the files storing
all the other metadata.
_______________________________________________
stgit-users mailing list
[email protected]
https://mail.gna.org/listinfo/stgit-users
