git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Rollback of git commands

From
Jon Smirl <jonsmirl@gmail.com>
Date
Nov 28, 2007, 04:37 UTC
Message-ID
<9e4733910711272037r2ce3ed01y31ec8531f5803efe@mail.gmail.com>
In-Reply-To
<BAYC1-PASMTP02DBA3FB25E09FE45F0BF2AE770@CEZ.ICE>
On 11/27/07, Sean <seanlkml@sympatico.ca> wrote:
Show 25 quoted lines
> 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@gmail.com
Previous: SeanNext: Sean
Message 14 of 31 in “Rollback of git commands”
  1. Jon SmirlNov 27, 2007
  2. Junio C HamanoNov 28, 2007
  3. Jon SmirlNov 28, 2007
  4. Jon SmirlNov 28, 2007
  5. David SymondsNov 28, 2007
  6. Ingo MolnarNov 28, 2007
  7. Sergei OrganovNov 28, 2007
  8. Nicolas PitreNov 28, 2007
  9. Geert BoschNov 28, 2007
  10. Jeff KingNov 28, 2007
  11. Jon SmirlNov 28, 2007
  12. Jeff KingNov 28, 2007
  13. SeanNov 28, 2007
  14. Jon SmirlNov 28, 2007
  15. SeanNov 28, 2007
  16. Jon SmirlNov 28, 2007
  17. Nicolas PitreNov 28, 2007
  18. Jon SmirlNov 28, 2007
  19. Nicolas PitreNov 28, 2007
  20. Jon SmirlNov 28, 2007
  21. Nicolas PitreNov 28, 2007
  22. Jon SmirlNov 28, 2007
  23. Karl HasselströmNov 29, 2007
  24. Junio C HamanoNov 28, 2007
  25. Karl HasselströmNov 28, 2007
  26. Jon SmirlNov 28, 2007
  27. Daniel BarkalowNov 28, 2007
  28. Steven GrimmNov 28, 2007
  29. Daniel BarkalowNov 28, 2007
  30. Jon SmirlNov 28, 2007
  31. Theodore TsoNov 29, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.