On 11/27/07, Sean <seanlkml@xxxxxxxxxxxx> wrote: > On Tue, November 27, 2007 8:33 pm, Jon Smirl said: > > Hi Jon, > > > I'm only looking for a command that would rollback the effect of > > changes to the object store (you don't have to remove the objects). > > Losing complex staging would be ok since it can be recreated. > > > > Let's take my recent problem as an example. I typed 'git rebase > > linus/master' instead of 'stg rebase linus/master'. Then I typed 'stg > > repair'. The repair failed and left me in a mess. Both of these are > > easy to rollback except for the fact that stg has stored a bunch of > > state in .git/*. > > > > After doing the commands I located my last commit before the rebase > > and edited master back to it. But my system was still messed up since > > moving master got me out of sync with the state stg stored in .git/*. > > The 'stg repair' command had changed the stored state. > > From your description is seems that Git proper was able to handle the > situation just fine. It sounds instead like you're describing a problem > with Stg where it became confused without a way to restore _its_ meta > data. There's not much Git itself can do to help in this situation > unless Stg stores all of its meta-data as standard Git objects, rather > than just using the .git directory. Patch management is an important part of the work flow. I would hope that git implements patch management as a core feature in future versions. stgit/guilt/quilt are valuable since they blazed the trail and figured out what commands are useful. As time passes these features can become more highly integrated into core git. Of course you've never screwed up a repository using git commands, right? I've messed up plenty. A good way to mess up a repo is to get the data in .git/* out of sync with what is in the repo. I'm getting good enough with git that I can fix most mess up with a few edits, but it took me two years to get to that point. Rolling back to a check point is way easier. User error and a command failing are both equally valid ways to mess up a repo. -- 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
