On Mon, 20 Nov 2006 23:57:16 +0100, Jakub Narebski wrote: > > The multiple-porcelains idea seems like a mistake to me--it'd be fine if > > you're just adding new features on the side, but who wants to learn > > entirely different sets of commands, with subtly different syntax, > > semantics, and feature sets, for doing the same thing? > > I don't think so. StGit seems that way because it mainly adds new feature: > patch management. But it can be used both as standalone SCM (like Quilt), > or as a tool to manage patches in branch (rebase/cherry-pick on steroids). From my inspection, StGit works just fine in its "standalone SCM" role, but falls over somewhat if using it as an additional tool alongside git itself for a few reasons: * There's a two-world-view problem with extra commands just to translate back and forth (assimilate, commit, uncommit, etc.) * The new references that StGit introduces can lead to collisions, (it happened to me anyway---I ended up having to rm -r .git/refs/bases or whatever just to make the ambiguity go away and let me get work done with git again). So, for use as something separate from git, StGit might be just fine. Otherwise, for being just another tool for users of "git" the command-line tool, I agree that the current StGit design is a mistake. I'd much prefer to have a minimal set of new "git" sub-commands that introduce the new functionality without a separate command namespace and several sub-commands with redundant functionality compared to existing git sub-commands. -Carl
Attachment:
pgpV285s72t9G.pgp
Description: PGP signature