Re: stgit: lost all my patches again

From: Jon Smirl <jonsmirl@gmail.com>
Date: Nov 28, 2007, 16:21 UTC
Message-ID: <9e4733910711280821s3872eff5m95073ca6b1b8a689@mail.gmail.com>
In-Reply-To: <20071128160410.GB19302@diana.vm.bytemark.co.uk>

On 11/28/07, Karl Hasselström <kha@treskal.com> wrote:

Show 18 quoted lines

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

Show 41 quoted lines

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