On 17/06/07, Josef Sipek <jsipek@xxxxxxxxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
