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

From: Catalin Marinas <catalin.marinas@arm.com>
Date: Feb 13, 2006, 14:40 UTC
Message-ID: <tnxy80fe2zo.fsf@arm.com>
In-Reply-To: <20060210195914.GA1350@spearce.org>

Shawn Pearce <spearce@spearce.org> wrote:

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

Couldn't help replying to such a topic :-) (only that the ":" ending of the above phrase might make people think that some features you listed are not available in StGIT).

Without much testing, I think pg is a good tool but it is different from StGIT in many ways. It mainly resembles the topic branches way of working with the advantage of having them stacked on each-other. Each patch seems to be equivalent to a topic branch where you can commit changes. Rebasing a patch is equivalent to a merge in a branch with the merge commit having a general description like "Refreshed patch ..." and two parents - the new base and the old top.

While I don't say the above is a bad thing, it is pretty different from StGIT. With StGIT, the history of the tree only shows one commit per patch with the patch description chosen by the user. If you edit the description or modify the patch, the old patch or description is dropped from the main branch (visible via HEAD) and you only get the latest one. This clean history has many advantages when sending patches upstream either via e-mail or by asking for a pull.

Show 5 quoted lines

> - 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).

This is the case with StGIT as well. It doesn't usually require the use of GIT commands directly.

Show 6 quoted lines

> - 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.

There have been discussions to adding this to StGIT as well (and there is a patch already from Chuck). It is a good thing to have but I'm opposed to the idea of having the history accessible from the top of the patch. Since the patch can be refreshed indefinitely, it would make the main history (visible from HEAD) really ugly and also cause problems with people pulling from a tree. I prefer to have a separate command (like 'stg id patch/log') that gives access to the history.

Show 6 quoted lines

> - 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.

That's missing indeed in StGIT but it will be available in the next release. I didn't push this yet because I wasn't sure what to do with the refresh history of a patch.

Show 7 quoted lines

> - 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.

StGIT has been doing this from the beginning. You would need to run a 'stg clean' after a rebase (or push). I prefer to run this command manually so that 'stg series -e' would show the empty patches and let me decided what to do with them.

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

Might be possible but I haven't done any tests. There are some optimisations in StGIT that make it pretty fast: (1) if the base of the patch has not changed, it can fast-forward the pushed patches which is O(1) and (2) StGIT first tries to use git-apply when pushing a patch and use a three-way merge only if this fails (the operation usually succeeds for most of the patches). There are some speed problems with three-way merging if there are many file removals/additions because the external merge tool is called for each of them but the same problem exists for any other tool.

-- 
Catalin