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.
--
Catalin
On Fri, Jun 15, 2007 at 03:59:24PM +0100, Catalin Marinas 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.
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.
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,
--
Yann
From: Josef Sipek <hidden> Date: 2016-06-15 22:43:17
On Fri, Jun 15, 2007 at 03:59:24PM +0100, Catalin Marinas wrote:
Karl Hasselström [off-list ref] wrote:
quoted
On 2007-06-14 14:55:54 -0700, Steven Grimm wrote:
quoted
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.
Sorry I missed this thread...
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.
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).
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).
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.
--
Hegh QaQ law'
quvHa'ghach QaQ puS
From: Josef Sipek <hidden> Date: 2016-06-15 22:43:17
On Fri, Jun 15, 2007 at 10:01:39PM +0200, Yann Dirson wrote:
On Fri, Jun 15, 2007 at 03:59:24PM +0100, Catalin Marinas wrote:
...
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?
...
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.
--
The box said "Windows XP or better required". So I installed Linux.
On Fri, Jun 15, 2007 at 03:59:24PM +0100, Catalin Marinas wrote:
quoted
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
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.
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
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.
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.
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).
--
Catalin
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).
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
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 :-).
--
Catalin
On Sat, Jun 16, 2007 at 11:59:23PM -0400, Josef Sipek wrote:
quoted
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,
--
Yann.