On 11/28/07, Karl Hasselström <kha@xxxxxxxxxxx> 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@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
