On 2007-11-28 11:21:05 -0500, Jon Smirl wrote:
> On 11/28/07, Karl Hasselström <kha@xxxxxxxxxxx> 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@xxxxxxxxxxx
www.treskal.com/kalle
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
