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.
--
Karl Wiberg, [email protected]
subrabbit.wordpress.com
www.treskal.com/kalle
_______________________________________________
stgit-users mailing list
[email protected]
https://mail.gna.org/listinfo/stgit-users
