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
Quoted 5 lines · Steven Grimm
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?
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.
Signature · 2 lines
Karl Hasselström, [email protected] www.treskal.com/kalle
Quoted 11 lines · Karl Hasselström
Quoted 5 lines · Steven Grimm
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?
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 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.
Signature · 1 line
Catalin
Quoted 5 lines · Catalin Marinas
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.
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.
Quoted 4 lines
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).
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,
Signature · 1 line
Yann
Quoted 1 line · Yann Dirson
On Fri, Jun 15, 2007 at 03:59:24PM +0100, Catalin Marinas wrote:
...
Quoted 6 lines
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.
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?
...
Quoted 6 lines
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.
So, why do you use git? ;)
Josef "Jeff" Sipek.
Signature · 1 line
The box said "Windows XP or better required". So I installed Linux.
Quoted 8 lines · Josef Sipek
Quoted 6 lines
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.
So, why do you use git? ;)
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,
Signature · 1 line
Yann.
Quoted 4 lines · Josef Sipek
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.
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).
Quoted 2 lines
Btw, does git-prune & friends do the right thing and not destroy the patch-related objects?
StGIT patches are git-prune safe. The commit ids are stored in .git/refs/patches.
Quoted 8 lines
Quoted 6 lines
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.
So, why do you use git? ;)
Well, I guess he's mostly using StGIT which uses only the built-in GIT commands written in C :-).
Signature · 1 line
Catalin
Quoted 9 lines · Catalin Marinas
Quoted 8 lines · Karl Hasselström
Quoted 5 lines · Steven Grimm
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?
Quoted 3 lines
Quoted 3 lines
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.
Sorry I missed this thread...
Quoted 5 lines
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.
Catalin: Perhaps a comparison table might be in order? This is most definitely not the first time this question has been asked.
Quoted 2 lines
Are the guilt patches accessible as commit objects at the top of the stack?
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).
Quoted 2 lines
StGIT might have some more features as it is older but I see a lot of development is going on with guilt.
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).
Quoted 2 lines
I would welcome such a discussion (so please keep me cc'ed) as we can share the experience with various issues.
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.
Signature · 2 lines
Hegh QaQ law' quvHa'ghach QaQ puS
Quoted 9 lines · Josef Sipek
Quoted 5 lines · Catalin Marinas
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.
Catalin: Perhaps a comparison table might be in order? This is most definitely not the first time this question has been asked.
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.
Quoted 6 lines
Quoted 2 lines
Are the guilt patches accessible as commit objects at the top of the stack?
When you push a patch, you're doing:
git-apply && git-commit
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.
Quoted 3 lines
When you pop a patch, you're doing:
git-reset --hard HEAD^
StGIT uses git-read-tree as it is safer with unresolved conflicts and local changes.
Quoted 5 lines
Quoted 2 lines
StGIT might have some more features as it is older but I see a lot of development is going on with guilt.
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.
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.
Quoted 3 lines
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).
StGIT started with these too but it grew to 41.
Quoted 3 lines
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.
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).
Signature · 1 line
Catalin