StGIT vs. guilt: What's the difference?

I've asked this on IRC a couple times and nobody seemed to have a good answer, so: These two tools seem like they are solving the same general problem using similar approaches. They are both under active development. In what areas is each of them stronger than the other? Why would one choose to use one of them instead of the other?

-Steve

On 2007-06-14 14:55:54 -0700, Steven Grimm wrote:

I have never had a close look at guilt, but from what I remember it stores patches as plain old plaintext patches (corrections to this statement welcome). StGIT uses git's object database.

I doubt there's anything that one model can handle that the other cannot; the question is whether the two _implementations_ are feature equivalent or not. And I can't answer that, since I know too little about guilt.

I'm guessing guilt's creator might be a bit more qualified to answer; from what I recall, he looked at StGIT, but decided to build his own tool because StGIT did not meet his requirements.

Karl Hasselström <kha@treskal.com> wrote:

I haven't tried quilt either but, if it uses plain text patches, the disadvantage might be the losing of the three-way merge when pushing a patch onto the stack. The solution is to remember which commit the patch applies to, switch the tree, apply the patch and merge with HEAD.

Are the guilt patches accessible as commit objects at the top of the stack?

StGIT might have some more features as it is older but I see a lot of development is going on with guilt. Another difference is that StGIT is written in Python and guilt uses shell scripts (some people don't like the dependency on Python).

I would welcome such a discussion (so please keep me cc'ed) as we can share the experience with various issues.

On Fri, Jun 15, 2007 at 03:59:24PM +0100, Catalin Marinas wrote:

Note that I haven't tried guilt either.

However, storing diffs is certainly a great way to interact with legacy SCMs, and there are situations where guilt is certainly more suited than stgit. Eg, on a project where you have to use CVS, and you have to maintain changes to a Linux kernel, and you want to store the history of a series of patches, guilt will be much easier to use than stgit.

We may even want to implement something in stgit to ease such integration with legacy SCMs - eg. an option to auto-export the stack on push/refresh should not be too hard to implement.

Well, people may not like python, but IMHO it is a lot easier to learn it if you don't know it (that's what I did, although I did not start from zero), than writing a robust and maintainable software of even moderate complexity in shell script. Shell script may be good for prototyping or gluing tools in a simple way, but for advanced sofware on which to rely to store my own data, it is just not really suited.

Best regards,

On Fri, Jun 15, 2007 at 10:01:39PM +0200, Yann Dirson wrote:

...

Then there is the psychological effect. If I have a directory full of patch(1) compatible diff files, I can forget about guilt and just use the diff files directly. With stgit's way of storing the patches, I'd assume things can get a bit harder if you just want to give up on stgit.

Btw, does git-prune & friends do the right thing and not destroy the patch-related objects?

...

So, why do you use git? ;)

Josef "Jeff" Sipek.

On 17/06/07, Josef Sipek <jsipek@fsl.cs.sunysb.edu> wrote:

I do this a lot to refine patches but I export the patch and re-import it (I can even merge it with the old version using 'stg fold --threeway' and it will prompt me for the differences via xxdiff or emacs).

StGIT patches are git-prune safe. The commit ids are stored in .git/refs/patches.

Well, I guess he's mostly using StGIT which uses only the built-in GIT commands written in C :-).

On Sat, Jun 16, 2007 at 11:59:23PM -0400, Josef Sipek wrote:

There is no such problem in git, since only some porcelain commands are still written in shell - and anyway C rewrites are quite fashionable those days ;)

Best regards,

On Fri, Jun 15, 2007 at 03:59:24PM +0100, Catalin Marinas wrote:

 
Sorry I missed this thread...

 
Catalin: Perhaps a comparison table might be in order? This is most
definitely not the first time this question has been asked.

When you push a patch, you're doing:
	
	git-apply && git-commit

When you pop a patch, you're doing:

	git-reset --hard HEAD^

So, once a patch is pushes, it is a separate commit in the git tree, and one can run any valid git command on it.

Now, of course the actual implementation is little bit more complex (e.g., using git-write-tree and git-commit-tree, as well as allowing to pop several patches at the same time).

I haven't looked at stgit in a number of months, but stgit most likely has many features which make use of the extra metadata stored.

I'm trying to take the simpler approach - most of the time, the user just want to push, refresh, and pop. With that said, there are plenty of useful commands (26 as of now).

Same here.

One additional thing. About four months ago, I've heard that stgit tends to blow up when you switch branches using git-checkout - guilt of course doesn't :) My information may be outdated, so corrections are welcome.

Josef "Jeff" Sipek.

On 17/06/07, Josef Sipek <jsipek@fsl.cs.sunysb.edu> wrote:

Yes, a table on a wiki (maybe a neutral one like git.or.cz?) would be good as it is easier to keep up to date.

StGIT's behaviour is more like:

  (git-apply || git-recursive-merge) && git-commit

i.e. if simple git-apply fails, it tries a proper three-way merge and can automatically invoke a graphical merge tool (xxdiff, emacs etc.).

The input to git-apply is generated by git-diff with the top and bottom commit ids of the patch as arguments. People mentioned that would be good to keep the plain diff and just apply it but we might still need to generate the patch after a push and hence call git-diff. It might work if we only regenerate the patch when git-apply fails and we run a recursive merge. Actually StGIT notifies you when the 'push' resulted in a modified patch so that one can re-export it.

Aome other features of 'push' is automatic detection of patches merged upstream (either by trying a reverse-apply or an empty patch resulting from a three-way merge). It can also do fast-forwarding if the base tree hasn't changed.

StGIT uses git-read-tree as it is safer with unresolved conflicts and local changes.

Most of the metada could actually be generated from the commit object. We just store it for performance. However, with some recent DAG patches from Karl, we plan to get this information directly from the repository.

StGIT started with these too but it grew to 41.

Not sure what you mean but it is safe to use git-checkout to switch branches and use them with StGIT afterwards, assuming they were initialised for StGIT (though StGIT has its own command for managing branches).

Some other useful commands in StGIT are 'mail' (to SMTP or mbox), 'export' (to quilt series), 'import' (from various sources like quilt series, e-mail message, mbox). It also support templates for the mail and export commands and various configuration options (shares the .git/config file and adds a [stgit] section).