StGIT vs. guilt: What's the difference?

StGIT vs. guilt: What's the difference?

[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?

-Steve

Re: StGIT vs. guilt: What's the difference?

[Karl Hasselström]

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

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

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: StGIT vs. guilt: What's the difference?

[Catalin Marinas]

Karl Hasselström <kha@treskal.com> wrote:
> On 2007-06-14 14:55:54 -0700, Steven Grimm wrote:
>
>> 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

Re: StGIT vs. guilt: What's the difference?

[Yann Dirson]

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

Re: StGIT vs. guilt: What's the difference?

[Josef Sipek]

On Fri, Jun 15, 2007 at 03:59:24PM +0100, Catalin Marinas wrote:
> Karl Hasselström <kha@treskal.com> wrote:
> > On 2007-06-14 14:55:54 -0700, Steven Grimm wrote:
> >
> >> 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

Re: StGIT vs. guilt: What's the difference?

[Josef Sipek]

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.

Re: StGIT vs. guilt: What's the difference?

[Catalin Marinas]

On 17/06/07, Josef Sipek <jsipek@fsl.cs.sunysb.edu> wrote:
> 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.
>
> 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.

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

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

Re: StGIT vs. guilt: What's the difference?

[Catalin Marinas]

On 17/06/07, Josef Sipek <jsipek@fsl.cs.sunysb.edu> 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.

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.

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

Re: StGIT vs. guilt: What's the difference?

[Yann Dirson]

On Sat, Jun 16, 2007 at 11:59:23PM -0400, Josef Sipek wrote:
> > 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.