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

I have used StGit (wonderfull tool) to manage patches on git branch gitweb/web. Unfortunately, I have named stg branch the same as git branch. When removing stg branch (I wanted to remove heads/base/gitweb/web) using "stg branch --delete gitweb/web" it deleted also git branch when I wanted to remove only the StGit managed indicator. Fortunately I was able to recover the branch from reflog, as StGit didn't delete reflog with deletion of git branch.

Perhaps that is correct behavior... but certainly unexpected.

Stacked GIT 0.11 git version 1.4.3.4 Python version 2.4.3 (#1, Jun 13 2006, 16:41:18) [GCC 4.0.2 20051125 (Red Hat 4.0.2-8)]

Jakub Narebski <jnareb@gmail.com> writes:

I am also a novice who recently started appreciating the convenience of StGIT. I _think_ the usage StGIT expect us to follow is to run "stg clean" to make the series empty, and not worry about leftover refs/bases/ at all, but I may well be mistaken.

On Mon, Nov 20, 2006 at 10:01:44PM +0100, Jakub Narebski wrote:

You probably actually had to "stg branch --delete --force", didn't you?

What you want is "stg commit".

I think "stg branch --delete" is pretty clearly named and documented....

The idea I guess was to make it possible to use stgit (and only stgit) for everything, and never type a git command. It might have been better to make stgit only manage patch series, and admit that people should use git for the rest. Then it might work more like you expect.

J. Bruce Fields wrote:

Nope. "stg branch --delete gitweb/web"

No. Whole stack was committed, I wanted only get rid of heads/base/gitweb/web (of StGit managed branch indicator).

I thought it delete only stg branch, refs/base/gitwbe/web, and not
refs/heads/gitweb/web.
 

Yes, I expected to use StGit as a kind of preprocessing (branch preparation) for git.

On Mon, Nov 20, 2006 at 11:37:54PM +0100, Jakub Narebski wrote:

Oh, right, got it.

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?

J. Bruce Fields wrote:

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

On Mon, 20 Nov 2006 23:57:16 +0100, Jakub Narebski wrote:

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

Carl Worth <cworth@cworth.org> wrote:

I initially opposed to commands like "uncommit" since people shouldn't modify the history. I currently see the assimilate/uncommit only as a way to fix mistakes of committing with GIT when you actually wanted an StGIT patch. I rarely use these commands.

I use StGIT in maintainer mode as well and the only additional command is "commit" to permanently store the patches and freeze the history before pushing the changes to the public repository.

I find the refs/bases useful, for example when invoking gitk I can see where the base of the stack is. You can also use the base in plain "git" commands.

I personally don't like mixing StGIT and GIT commands unnecessarily, unless there is no other option (like "git log" since "stg log" has a different meaning). There are people (including me) who use StGIT almost exclusively, without relying on the GIT commands. That's why I duplicated some of the GIT commands.

I don't think there is a problem with StGIT's design but rather a workflow one (which neither GIT nor StGIT have clearly documented it, you can see many people writing their own scripts to do the things they need). For example, I thought "uncommit" only as a way to fix a mistaken commit but someone posted a bug report that it wasn't possible to uncommit hundreds of commits and going over merges. This was not the intended behaviour but you can't force people not to be inventive :-).

I find the GIT command space to be pretty cramped and without a clear separation between low-level commands and porcelain ones. Adding even more functionality for patch management would scare beginners even more (had the GNU Arch experience where you need a steep learning curve).

On 2006-11-21 10:06:30 +0000, Catalin Marinas wrote:

I, on the other hand, tend to freely mix git and stgit commands. For example, I often commit things with the git emacs modes, but I do all my merging with stgit.

This is all very straightforward once you learn that stgit just adds a thin layer of extra metadata on top of git. All the really valuable information is stored in git; what stgit adds is e.g. convenient names for patches, and the distinction between commits that are patches and commits that aren't (so that you won't edit supposedly immutable history by mistake). To me, stgit is a convenient way to edit git history, which happens to make patchset maintenance very easy.

However, interoperability could be much better than it is. I think stgit maintains too much extra metadata on top of what git already has.

On 20/11/06, Jakub Narebski <jnareb@gmail.com> wrote:

Well, there is no such thing as a stg branch. StGIT shares the branch structure with GIT and the "branch" command works on the whole GIT branch, with some additional things for handling the patches. Once a GIT branch is StGIT-initialised (either by being created with "stg branch" or by "stg init") it will always remain a StGIT branch and get a reference in refs/bases/.

I've never thought anyone would see a different meaing for the "branch" command. What you wanted to do was the reverse of the "init" command. Maybe something like "uninit" or a "--uninit" option to "branch".

Catalin Marinas wrote:

Yes, that is what I wanted. "stg branch --unmanage" or something like that.

By the way, why "stg branch --delete" doesn't remove reflog? Not that I'm complaining, because it sure saved some work when resurrecting branch, and I didn't loose reflog info.

Jakub Narebski <jnareb@gmail.com> wrote:

I'll put it on my to-do list.

Reflogs came into GIT after the StGIT branch command and never looked at them in detail. And maybe it should not touch the reflog info, especially for situations like this, unless GIT has a mechanism for a trash bin (StGIT has one for patches - .git/patches/<branch>/trash/ - but undocumented)

Catalin Marinas wrote:

Well, I'm asking because "git branch -D" deletes also reflog. So I'm worrying if StGit works with packed refs (although one usually do not pack branches/heads, only tags).