Re: stgit: lost all my patches again

From: Karl Hasselström <kha@treskal.com>
Date: Oct 4, 2007, 15:38 UTC
Message-ID: <20071004153830.GA21717@diana.vm.bytemark.co.uk>
In-Reply-To: <9e4733910710040606j75caa6bcn1e97e59c1285eb4b@mail.gmail.com>

On 2007-10-04 09:06:22 -0400, Jon Smirl wrote:

Show 12 quoted lines

> On 10/4/07, Karl Hasselström <kha@treskal.com> wrote:
>
> > Mmmph. This is not the only StGit command that's apparently not
> > safe to run from a subdirectory. See e.g.
> > https://gna.org/bugs/?9986.
> >
> > I plan to do some StGit hacking this weekend. I guess subdirectory
> > safeness ought to be at the top of my list ...
>
> Isn't a rollback log fairly easy to implement? Is there a single SHA
> after each operation? If so just record the commands and the sha to
> rollback.

Yeah, conceptually it's simple. The only major complication there is if you want to allow undo both at the whole-stack level and on single patches.

> I have also messed things up more than once using 'git merge linus'
> instead of 'stg rebase linus'. Should 'git merge' have a check to
> see if stg is active and refuse to run?

I've always felt that git shouldn't have to know about third-party tools.

stg will detect that you've made git commits on top of the stack. There's a command to turn them into patches -- but not if they are merges, of course. In a sufficiently bleeding-edge StGit, assimilate will tell you something like,

  14 patches are hidden below the merge commit 4711abcd,
  and will be considered unapplied.

at which point you can easily git-reset to below the merge and run assimilate again.

This is of course less user-friendly than having git refuse to commit a merge in the first place. Hmmm, a commit hook could probably do magic here ... it could even turn regular commits into patches on the fly. I'll have to look up how commit hooks work.

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