On Thu, 2013-07-04 at 02:24 +0200, Karl Wiberg wrote: > On Thu, Jul 4, 2013 at 2:09 AM, Waskiewicz Jr, Peter P > <[email protected]> wrote: > > > On Wed, 2013-07-03 at 22:57 +0200, Karl Wiberg wrote: > > > > > One design that leaps to mind is to use empty patches for cover > > > letters (with special headers in the commit message to mark it as > > > a cover letter and to store the recipient list), and let each > > > cover letter apply to the patches following it, until the end of > > > the stack or the next cover letter. > > > > This is probably close. Using empty patches would pollute the > > commit indices, with stuff for StGit maintenance. I'm not sure if > > the upstream kernel maintainers would like this, since they'd either > > have to manage not applying that patch, or apply patches that have > > zero change. > > Oh, we wouldn't try to make anyone else accept those empty patches: > > * stg mail would use them for cover letter generation, not mail them > out as patches. > > * stg commit would skip them, and only commit the "real" patches. > > 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. > 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. Cheers, -PJ _______________________________________________ stgit-users mailing list [email protected] https://mail.gna.org/listinfo/stgit-users
