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