Re: [ANNOUNCE] pg - A patch porcelain for GIT

[Petr Baudis <pasky@suse.cz>]

  Hi,

Dear diary, on Fri, Feb 10, 2006 at 10:17:40PM CET, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> > I just posted the first public version of pg, a GIT porcelain for
> > managing patches.  Think StGIT, but better in some ways:
> 
>   it sounds interesting. I've been thinking about wrapping some patch
> queue tool in Cogito (post-1.0) and pg might be a better choice than
> StGIT.

  so I've used it a bit and I'm going back to StGIT, at least for now.
It is not really usable for me so far, since it is missing two crucial
things:

	* Patch description tracking. Patch description is almost as
	important as patch contents for me, and pg just doesn't track it
	for now.  It would be best if it just seeded the patch
	description by the first commit message and then allow you edit
	it at the refresh time.

	* Mail interface. StGIT can pre-fill the patch description with
	my signoff line, but more importantly when I write

		stg mail patchname

	it will mail the patch to the addresses I configured it to,
	prepend [PATCH] to the subject line and stuff.

  So, my patchqueue workflow is "I do some random third-party patches
for some software and want to manage, update, and submit them easily."
PG does not make it much easier now, unfortunately.

  Some common gripes for both StGIT and pg (well, I'm using some
ridiculously old StGIT version, so this may not apply anymore there):

	* stg new --force - seriously, what's the point?! I always to
	the change first and when it's any good, I want to create a
	patch for it.

	* I can't just get the patch in its "canonical ready-to-mail
	form" on stdout so that I could easily review it. Why is
	pg-export insisting to dump it to a file?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams