Re: stgit: lost all my patches again

["Jon Smirl" <jonsmirl@gmail.com>]

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