[ANNOUNCE] pg - A patch porcelain for GIT

[Shawn Pearce <spearce@spearce.org>]

I just posted the first public version of pg, a GIT porcelain for
managing patches.  Think StGIT, but better in some ways:

Feature Summary:

- Maximum compatibility with other GIT porcelains.

    pg was designed to interoperate with core GIT and the other
    GIT porcelains as much as possible.  GIT favorites like git-am
    can be used to modify a pg managed patch, and vice-versa,
    and without requiring changes to the other GIT tools.

- Simplified command line user interface.

    pg tries to simplify GIT by 'hiding' the index and behaving like
    more traditional SCMs which only look at `HEAD` (last commit)
    and the working directory (files).

- Preserves change history of patches.

    The complete change history associated with each patch is
    maintained directly within GIT.  By storing the evolution of a
    patch as a sequence of GIT commits standard GIT history tools
    such as gitk can be used.

- Its prune proof.

    The metadata structure is stored entirely within the refs
    directory and the object database, which means you can safely use
    git-prune without damaging your work, even for unapplied patches.

- Preserves patch series during clone.

    The metadata structure used by pg allows git-clone to preserve
    the patch series information, without changes required to
    git-clone.  (Patch series information is not preserved during
    git-pull/git-push however.)

- Mix and matching of changes (bug fixes/features).

    By maintaining changes as individual patches it is possible to
    apply individual changes to the current working directory and
    to unapply them just as easily.

- Automatic detection (and cancellation) of returning patches.

    pg automatically detects when a patch is received from
    the upstream GIT repository during a pg-rebase and deletes
    (cancels) the local version of the patch from the patch series.
    The automatic cancelling makes it easy to use pg to track and
    develop changes on top of a GIT project.

- Fast

    pg operations generally perform faster than StGIT operations,
    at least on my large (~7000 file) repositories.


And for those so inclined:

  Homepage:       http://www.spearce.org/projects/scm/pg/
  GIT Repository: http://www.spearce.org/projects/scm/pg.git


-- 
Shawn.