stgit: lost all my patches again

stgit: lost all my patches again

[Jon Smirl]

I believe this command did it:

stg refresh -p pcm030_bsp_powerpc -e

that patch whitespace errors in it
I edited the description and removed the last line
it was 10th patch down in the stack

for some reason the refresh from that command didn't close.
Then stg pushed all the patches back after the edit and they got
included into that patch.

stg should definitely have an assert that the previous patch is closed
before auto pushing.
There is a bug somewhere that caused that edit refresh not to get closed.

I am using stg version:
5ae6fcce77a29221e15f6a4e8348bd4276960ba1

It might also be good to make a log that lets me rollback commands.
All of the info is still in the system.

This refresh failed to close:
jonsmirl@terra:~/mpc5200b$ stg log pcm030_bsp_powerpc
95a8e03b [push   ]                               Thu Oct  4 00:27:53 2007 -0400
6094a0a5 [refresh]                               Thu Oct  4 00:00:41 2007 -0400
0c4f5480 [push(f)]                               Wed Oct  3 22:10:38 2007 -0400
9a685ae9 [push(f)]                               Wed Oct  3 22:05:47 2007 -0400

This push ended up in the bsp patch:
jonsmirl@terra:~/mpc5200b$ stg log mpc52xx_restart
801962ed [push   ]                               Thu Oct  4 00:33:42 2007 -0400
9e0c7417 [push   ]                               Thu Oct  4 00:27:53 2007 -0400
37822491 [push   ]                               Thu Oct  4 00:00:41 2007 -0400
9aff07ff [push(f)]                               Wed Oct  3 22:10:38 2007 -0400
c41c9cb3 [push(f)]                               Wed Oct  3 22:05:47 2007 -0400

and so one for nine more patches.
The ten messed up patches still have their descriptions, the are just
missing the changes.

---------------------------------
After an export stg puts the patches into patches-m25
Looking back in my command logs I had done:
  stg export
  cd patches-m25
  grep for some things
  stg refresh -p pcm030_bsp_powerpc -e

I did the 'stg refresh' from a directory that was not being tracked by git.
It is in the .gitignore list. This appears to be the root of the problem.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: stgit: lost all my patches again

[Karl Hasselström]

On 2007-10-04 01:29:17 -0400, Jon Smirl wrote:

> for some reason the refresh from that command didn't close. Then stg
> pushed all the patches back after the edit and they got included
> into that patch.

That's really weird. As far as I know there isn't a concept of
"closed" patches in StGit -- there's no need, because they're always
closed!

> I did the 'stg refresh' from a directory that was not being tracked
> by git. It is in the .gitignore list. This appears to be the root of
> the problem.

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

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

Re: stgit: lost all my patches again

[Jon Smirl]

On 10/4/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-10-04 01:29:17 -0400, Jon Smirl wrote:
>
> > for some reason the refresh from that command didn't close. Then stg
> > pushed all the patches back after the edit and they got included
> > into that patch.
>
> That's really weird. As far as I know there isn't a concept of
> "closed" patches in StGit -- there's no need, because they're always
> closed!

Must be the other way around then, the next nine patches didn't get
opened right. Their descriptions ended up in the right place but the
deltas all ended up in the first patch.

> > I did the 'stg refresh' from a directory that was not being tracked
> > by git. It is in the .gitignore list. This appears to be the root of
> > the problem.
>
> 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 ...
>
> --
> Karl Hasselström, kha@treskal.com
>       www.treskal.com/kalle
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: stgit: lost all my patches again

[Jon Smirl]

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.

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?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: stgit: lost all my patches again

[Karl Hasselström]

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

> 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

Re: stgit: lost all my patches again

[David Brown]

On Thu, Oct 04, 2007 at 10:33:04AM +0200, Karl Hasselström wrote:

>> I did the 'stg refresh' from a directory that was not being tracked
>> by git. It is in the .gitignore list. This appears to be the root of
>> the problem.
>
>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 get an "Error: This item is private" from that page, so I'm not sure what
that is.

Just yesterday, I had 'stg push' empty out my patches when I ran it from a
subdirectory.  Fortunately, in this case, the old versions were in the log,
but I can imagine someone less familiar with what git and stgit are doing
not knowing how to recover this.

David

Re: stgit: lost all my patches again

[Karl Hasselström]

On 2007-10-04 08:45:08 -0700, David Brown wrote:

> On Thu, Oct 04, 2007 at 10:33:04AM +0200, Karl Hasselström wrote:
>
> > > I did the 'stg refresh' from a directory that was not being
> > > tracked by git. It is in the .gitignore list. This appears to be
> > > the root of the problem.
> >
> > 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 get an "Error: This item is private" from that page, so I'm not
> sure what that is.

Bleh. For some reason that bug was marked "private" (possibly because
it was posted anonymously), and I didn't realize because _I_ could
read it just fine ... Sorry about that; I've made it public now.

> Just yesterday, I had 'stg push' empty out my patches when I ran it
> from a subdirectory. Fortunately, in this case, the old versions
> were in the log, but I can imagine someone less familiar with what
> git and stgit are doing not knowing how to recover this.

Yep. I hadn't really realized how bad this was, because I always run
stg from the root dir. Wonder how I picked up that habit? ;-)

Thanks for the report.

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

stgit: lost all my patches again

[Jon Smirl]

My fingers are too trained in doing "git rebase linus/master" instead
of "stg rebase linus/master". This has resulting in me losing my patch
stack again. I updated stg to the current version and tried "stg
repair"  put all my patches are still empty.

What's the easiest way to recover?

Can we add a check in "git rebase" so that it will refuse to run if
stg is active?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: stgit: lost all my patches again

[Jakub Narebski]

Jon Smirl wrote:

> My fingers are too trained in doing "git rebase linus/master" instead
> of "stg rebase linus/master". This has resulting in me losing my patch
> stack again. I updated stg to the current version and tried "stg
> repair"  put all my patches are still empty.
> 
> What's the easiest way to recover?

git reset --hard $(cat .git/patches/<branch>/orig-base)

or perhaps "git reset --hard ORIG_HEAD"; with new rebase working on
detached head "git reset --hard @{1}".

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: stgit: lost all my patches again

[Jon Smirl]

On 11/27/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> My fingers are too trained in doing "git rebase linus/master" instead
> of "stg rebase linus/master". This has resulting in me losing my patch
> stack again. I updated stg to the current version and tried "stg
> repair"  put all my patches are still empty.
>
> What's the easiest way to recover?

I recovered, which wasn't too bad since I had exported the stack about
an hour earlier. I played around trying to recover the tree for a
while and then gave up and whacked it. I used my export and then I
extracted the last hours worth of changes from the old tree.

As Jakub pointed out to me "git reset --hard $(cat
.git/patches/<branch>/orig-base)" would have recovered from the rebase
command. But I had already typed 'stg repair' which compounded the
mess.

> Can we add a check in "git rebase" so that it will refuse to run if
> stg is active?

This is way too easy to do. One simple mistype of 'git' for 'stg' and
you're in a mess.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: stgit: lost all my patches again

[Karl Hasselström]

On 2007-11-27 18:12:49 -0500, Jon Smirl wrote:

> As Jakub pointed out to me "git reset --hard $(cat
> .git/patches/<branch>/orig-base)" would have recovered from the
> rebase command. But I had already typed 'stg repair' which
> compounded the mess.

Unless it has a bug, the only thing "stg repair" will do is

  * create some new applied patches out of commits reachable from HEAD

  * mark some applied patches as unapplied

  * mark some unapplied patches as applied

in order to make sure that the applied patches are precisely those
that are reachable from HEAD, and that the sequence of applied patches
doesn't have "holes" in it (that is, commits that aren't patches).

In particular, it should not ever modify your existing patches, and it
will never move the branch head. Just resetting the branch head to
wherever you want it to be (and then running repair again) should fix
literally all problems.

> This is way too easy to do. One simple mistype of 'git' for 'stg'
> and you're in a mess.

You're right, this is not user friendly. A pre-rebase hook sounds like
a reasonable idea.

It would also be convenient with a post-commit hook that turns new
commits into patches automatically. And gives "git commit --amend" the
semantics of "stg refresh".

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

Re: stgit: lost all my patches again

[Jon Smirl]

On 11/28/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-11-27 18:12:49 -0500, Jon Smirl wrote:
>
> > As Jakub pointed out to me "git reset --hard $(cat
> > .git/patches/<branch>/orig-base)" would have recovered from the
> > rebase command. But I had already typed 'stg repair' which
> > compounded the mess.
>
> Unless it has a bug, the only thing "stg repair" will do is
>
>   * create some new applied patches out of commits reachable from HEAD
>
>   * mark some applied patches as unapplied
>
>   * mark some unapplied patches as applied

I did 'stg repair' after doing 'git rebase'. After the repair half of
my patches were marked as being applied and half not. The ones that
were applied were all empty. They were probably empty because my
original patches were still commited by stg in front of the rebase. I
couldn't figure out how to recover so I extracted the pre-rebase
commits manual, built a series file and started again on a new branch.

When I applied the patches to a clean branch none of them had conflicts.

> in order to make sure that the applied patches are precisely those
> that are reachable from HEAD, and that the sequence of applied patches
> doesn't have "holes" in it (that is, commits that aren't patches).
>
> In particular, it should not ever modify your existing patches, and it
> will never move the branch head. Just resetting the branch head to
> wherever you want it to be (and then running repair again) should fix
> literally all problems.

I did this:
all pataches were applied
git rebase
stg repair -- partial repair, some patches empty, half are pushed
moved HEAD back in front of rebase
stg repair - it show all my patches as popped, but when I started
doing command it complain that some commits that stg needed were not
there.

The complaint was caused by the first repair. The first repair altered
some of the stg state to point at commits past the rebase. That why I
wanted check point. At this point I could move the HEAD back without
also reverting the stgit state in .git/*


>
> > This is way too easy to do. One simple mistype of 'git' for 'stg'
> > and you're in a mess.
>
> You're right, this is not user friendly. A pre-rebase hook sounds like
> a reasonable idea.
>
> It would also be convenient with a post-commit hook that turns new
> commits into patches automatically. And gives "git commit --amend" the
> semantics of "stg refresh".
>
> --
> Karl Hasselström, kha@treskal.com
>       www.treskal.com/kalle
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: stgit: lost all my patches again

[Karl Hasselström]

On 2007-11-28 10:06:57 -0500, Jon Smirl wrote:

> I did this:
> all pataches were applied
> git rebase

At this point, a simple "git reset --hard HEAD@{1}" should have fixed
the problem. Not much use knowing that now, I know, but still ... :-)

> stg repair -- partial repair, some patches empty, half are pushed

Modulo any bugs, this should have adjusted the appliedness of your
patches to match the new HEAD (patches are applied iff they are
reachable from HEAD) and made patches of any non-patch commits sitting
between a patch and HEAD. Nothing else. In particular, it doesn't
change your existing patches or change HEAD, so those empty patches
were empty even before the repair. (Modulo any bugs, of course, but
that kind of bug seems really unlikely.)

> moved HEAD back in front of rebase
> stg repair - it show all my patches as popped,

That sounds OK. You reset HEAD to a commit early enough in history
that no patches are reachable from it.

> but when I started doing command it complain that some commits that
> stg needed were not there.

That sounds seriously broken. What exactly was the complaint? Missing
commit objects?

> The complaint was caused by the first repair. The first repair
> altered some of the stg state to point at commits past the rebase.

Yes. It would have made patches out of some of the rebased commits, in
order to give you a consistent state. For example, assume you started
with the following situation:

(cN are commits, pN are commits that are also StGit patches)

   ...---c0---c1---p0---p1---p2---p3---p4:HEAD

You git-rebase, causing a situation like this:

   ...---c0---c1---p0---p1---p2---p3---p4
                         \
                          c2---c3---c4---c5---c6---c7---c8:HEAD

"stg repair" at this point will see that p2..p4 should be unapplied
since they aren't reachable from HEAD, and c2..c8 need to be made
patches since they are on top of p1.

Generally, what you want to do is to git-reset to the commit you want
HEAD to be, and _then_ run stg repair.

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

Re: stgit: lost all my patches again

[Jon Smirl]

On 11/28/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-11-28 10:06:57 -0500, Jon Smirl wrote:
>
> > I did this:
> > all pataches were applied
> > git rebase
>
> At this point, a simple "git reset --hard HEAD@{1}" should have fixed
> the problem. Not much use knowing that now, I know, but still ... :-)
>
> > stg repair -- partial repair, some patches empty, half are pushed
>
> Modulo any bugs, this should have adjusted the appliedness of your
> patches to match the new HEAD (patches are applied iff they are
> reachable from HEAD) and made patches of any non-patch commits sitting
> between a patch and HEAD. Nothing else. In particular, it doesn't
> change your existing patches or change HEAD, so those empty patches
> were empty even before the repair. (Modulo any bugs, of course, but
> that kind of bug seems really unlikely.)

I don't know exactly what is going one, but all of my patches are in
commits in front of the rebase. I believe when they were applied
again, git detected that the changes were already in the tree and that
why the patches are empty. Normally stg would have popped all my
patches before doing the rebase.

I have messed the branch up doing manual recover, but the conditions
are easy enough to recreate.


>
> > moved HEAD back in front of rebase
> > stg repair - it show all my patches as popped,
>
> That sounds OK. You reset HEAD to a commit early enough in history
> that no patches are reachable from it.
>
> > but when I started doing command it complain that some commits that
> > stg needed were not there.
>
> That sounds seriously broken. What exactly was the complaint? Missing
> commit objects?
>
> > The complaint was caused by the first repair. The first repair
> > altered some of the stg state to point at commits past the rebase.
>
> Yes. It would have made patches out of some of the rebased commits, in
> order to give you a consistent state. For example, assume you started
> with the following situation:
>
> (cN are commits, pN are commits that are also StGit patches)
>
>    ...---c0---c1---p0---p1---p2---p3---p4:HEAD
>
> You git-rebase, causing a situation like this:
>
>    ...---c0---c1---p0---p1---p2---p3---p4
>                          \
>                           c2---c3---c4---c5---c6---c7---c8:HEAD
>
> "stg repair" at this point will see that p2..p4 should be unapplied
> since they aren't reachable from HEAD, and c2..c8 need to be made
> patches since they are on top of p1.
>
> Generally, what you want to do is to git-reset to the commit you want
> HEAD to be, and _then_ run stg repair.
>
> --
> Karl Hasselström, kha@treskal.com
>       www.treskal.com/kalle
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: stgit: lost all my patches again

[Karl Hasselström]

On 2007-11-28 11:21:05 -0500, Jon Smirl wrote:

> On 11/28/07, Karl Hasselström <kha@treskal.com> wrote:
>
> > On 2007-11-28 10:06:57 -0500, Jon Smirl wrote:
> >
> > > stg repair -- partial repair, some patches empty, half are pushed
> >
> > Modulo any bugs, this should have adjusted the appliedness of your
> > patches to match the new HEAD (patches are applied iff they are
> > reachable from HEAD) and made patches of any non-patch commits
> > sitting between a patch and HEAD. Nothing else. In particular, it
> > doesn't change your existing patches or change HEAD, so those
> > empty patches were empty even before the repair. (Modulo any bugs,
> > of course, but that kind of bug seems really unlikely.)
>
> I don't know exactly what is going one, but all of my patches are in
> commits in front of the rebase. I believe when they were applied
> again, git detected that the changes were already in the tree and
> that why the patches are empty. Normally stg would have popped all
> my patches before doing the rebase.

Ah, yes, if you "stg push" after the repair, that's what you can
expect to happen. And once you've done that, it gets a little messier
to recover. (Basically, what you'd do is delete the messed-up patches,
git-reset to where you were before the git-rebase, and then "stg
uncommit".)

> I have messed the branch up doing manual recover, but the conditions
> are easy enough to recreate.

So I guess "stg repair" is working as intended, and what needs
changing is its documentation: point out in greater detail that you
should

  1. Figure out where you _want_ HEAD to be.

  2. git-reset your way there.

  3. Run stg repair if necessary. (And if you just reset back to where
     StGit thinks you are, you don't need to. But it's safe to run
     repair in that case too -- it'll just do nothing.)

In that order.

The only thing repair does is fix up StGit's metadata to match what
HEAD is right now. If HEAD isn't what you want it to be, then you want
to fix that first. In particular, to just go back to where you were
the last time StGit heard from you, do

  $ git reset --hard $(stg id $(stg top))

We need a proper manual to explain this in. :-)

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

Re: stgit: lost all my patches again

[Jon Smirl]

On 11/28/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-11-28 11:21:05 -0500, Jon Smirl wrote:
>
> > On 11/28/07, Karl Hasselström <kha@treskal.com> wrote:
> >
> > > On 2007-11-28 10:06:57 -0500, Jon Smirl wrote:
> > >
> > > > stg repair -- partial repair, some patches empty, half are pushed
> > >
> > > Modulo any bugs, this should have adjusted the appliedness of your
> > > patches to match the new HEAD (patches are applied iff they are
> > > reachable from HEAD) and made patches of any non-patch commits
> > > sitting between a patch and HEAD. Nothing else. In particular, it
> > > doesn't change your existing patches or change HEAD, so those
> > > empty patches were empty even before the repair. (Modulo any bugs,
> > > of course, but that kind of bug seems really unlikely.)
> >
> > I don't know exactly what is going one, but all of my patches are in
> > commits in front of the rebase. I believe when they were applied
> > again, git detected that the changes were already in the tree and
> > that why the patches are empty. Normally stg would have popped all
> > my patches before doing the rebase.
>
> Ah, yes, if you "stg push" after the repair, that's what you can
> expect to happen. And once you've done that, it gets a little messier
> to recover. (Basically, what you'd do is delete the messed-up patches,
> git-reset to where you were before the git-rebase, and then "stg
> uncommit".)
>
> > I have messed the branch up doing manual recover, but the conditions
> > are easy enough to recreate.
>
> So I guess "stg repair" is working as intended, and what needs
> changing is its documentation: point out in greater detail that you
> should
>

After someone runs the wrong command their first instinct will be to
run stg repair. Can stg repair be made smart enough to not attempt a
repair if it is unable to do so and print a message referring people
back to the manual on how to move the head back?

When I ran stg repair after the wrong git rebase command, I compounded
the problem further.


>   1. Figure out where you _want_ HEAD to be.
>
>   2. git-reset your way there.
>
>   3. Run stg repair if necessary. (And if you just reset back to where
>      StGit thinks you are, you don't need to. But it's safe to run
>      repair in that case too -- it'll just do nothing.)
>
> In that order.
>
> The only thing repair does is fix up StGit's metadata to match what
> HEAD is right now. If HEAD isn't what you want it to be, then you want
> to fix that first. In particular, to just go back to where you were
> the last time StGit heard from you, do
>
>   $ git reset --hard $(stg id $(stg top))
>
> We need a proper manual to explain this in. :-)
>
> --
> Karl Hasselström, kha@treskal.com
>       www.treskal.com/kalle
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: stgit: lost all my patches again

[Karl Hasselström]

On 2007-11-28 11:58:14 -0500, Jon Smirl wrote:

> After someone runs the wrong command their first instinct will be to
> run stg repair. Can stg repair be made smart enough to not attempt a
> repair if it is unable to do so and print a message referring people
> back to the manual on how to move the head back?

Well, the thing is, it's never unable to repair.

However, I could add another repair mode: reset the branch head to the
latest point in the reflog where it was consistent with StGit's
metadata.

repair would have two flags to select the original or this new repair
mode, and if the user doesn't give either flag, repair points out that
she has two choices, and what they mean:

  "If you want to undo the last 3 git commands

     pull : Fast forward
     commit (amend): fix
     reset --hard kha/experimental: updating HEAD

   call stg repair --undo. If you want StGit to adjust to the new
   situation, call stg repair --assimilate."

> When I ran stg repair after the wrong git rebase command, I
> compounded the problem further.

Not that much. It was the push following the repair that killed you.
The repair alone is totally benign; doing

  $ stg repair && git reset --hard foobar && stg repair

gives the same result as just

  $ git reset --hard foobar && stg repair

except for creating a few new patches that you can safely delete.

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

Re: stgit: lost all my patches again

[Junio C Hamano]

"Jon Smirl" <jonsmirl@gmail.com> writes:

> Can we add a check in "git rebase" so that it will refuse to run if
> stg is active?

The pre-rebase hook has been there since early Feb 2006.

Re: stgit: lost all my patches again

[Jon Smirl]

On 11/27/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Jon Smirl" <jonsmirl@gmail.com> writes:
>
> > Can we add a check in "git rebase" so that it will refuse to run if
> > stg is active?
>
> The pre-rebase hook has been there since early Feb 2006.

Karl, Catalin, can stgit install a pre-rebase hook and disable 'git
rebase' when stg is active on the branch? This would keep me from
destroying my patch stack when my fingers get ahead of me. Might be
good to disable anything else that can cause damage too.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: stgit: lost all my patches again

[Karl Hasselström]

On 2007-11-27 21:59:00 -0500, Jon Smirl wrote:

> Karl, Catalin, can stgit install a pre-rebase hook and disable 'git
> rebase' when stg is active on the branch? This would keep me from
> destroying my patch stack when my fingers get ahead of me. Might be
> good to disable anything else that can cause damage too.

Mmmm. We'd have to define "damage"; "stg repair" can take care of
quite a lot of things nowadays. Committing new stuff on top of a patch
series is no problem, for example, and "git reset --hard HEAD^ && stg
repair" is equivalent to "stg pop". I can see how "git rebase" would
still be a nuisance, though.

Patch? :-)

Presumably, we'd want the hook to be a Python script, so as to

  * not make it more difficult to port StGit to Windows someday;

  * make it possible for the hook to call StGit functions; and

  * not force the project's contributors to learn more shell scripting
    than they have to. :-)

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