On 11/28/07, Nicolas Pitre <nico@xxxxxxx> wrote: > On Wed, 28 Nov 2007, Jon Smirl wrote: > > > On 11/28/07, Nicolas Pitre <nico@xxxxxxx> wrote: > > > On Tue, 27 Nov 2007, Jon Smirl wrote: > > > > > > > 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. > > > > > > The reflog contains all your check points, for every modifications you > > > make, even the stupid ones. You should look at it. > > > > The state contained in the other config files in .git/* is not getting > > check pointed. I can use reflog to move my branch heads around. But > > doing that does not undo the changes to the state recorded in .git/*. > > After the error I encountered I moved my branch head back, but the > > state stgit had stored in .git/* was out of sync with where the branch > > had been moved to. > > It's up to stgit to version control its state then. It may even use a > reflog for it. All the machinery is there already. Git has state in .git/* too, shouldn't it be version controlling it too? If git was version controlling the state in .git/* you'd have checkpoints with the ability to roll back. > > > Nicolas > - > 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 > -- 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
