On 11/28/07, Karl Hasselström <kha@xxxxxxxxxxx> wrote: > 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 > 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@xxxxxxxxxxx > www.treskal.com/kalle > -- Jon Smirl jonsmirl@xxxxxxxxx - 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
