Re: [BUG] StGit removed git branch of the same name as StGit branch

[Carl Worth <cworth@cworth.org>]

[-- Attachment #1: Type: text/plain, Size: 1578 bytes --]

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 #2: Type: application/pgp-signature, Size: 189 bytes --]