From: Karl Hasselström Date: Thu, 04 Oct 2007 15:38:30 GMT Subject: Re: stgit: lost all my patches again 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: > On 10/4/07, Karl Hasselström 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