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

Re: [RFC] undo and redo

From
CBCarl Baldwin <cnb@fc.hp.com>
Date
Aug 24, 2005, 19:56 UTC
Message-ID
<20050824195615.GA693@hpsvcnb.fc.hp.com>
In-Reply-To
<Pine.LNX.4.58.0508241148480.3317@g5.osdl.org>
On Wed, Aug 24, 2005 at 11:51:32AM -0700, Linus Torvalds wrote:
Show 16 quoted lines
> 
> 
> On Wed, 24 Aug 2005, Carl Baldwin wrote:
> >
> > Oops.  I forgot to actually exit from the script if git-diff-files is
> > non-empty.
> > 
> > Also, looking at it now, I don't think keeping undo information in a
> > stack is the right thing.  But keeping more than just one would be good.
> > Oh well, my first shot is never perfect.  ;-)
> 
> I would actually argue that
> 
> 	git checkout -b newbranch <undo-point>
> 
> is the perfect undo.

Yes, this does the job nicely. I've used it like this effectively. I meant for undo/redo to be a lighter weight way of moving (uncommitted) changes out of the way briefly and then replaying them onto the working directory later.

Show 5 quoted lines
> It leaves the old state in the old branch, and creates a new branch (and
> checks it out) with the state you want to revert to. The advantage is
> exactly that there is no "stack" of undo's: you can have multiple
> independent undo's pending, and you can continue development at any of 
> them. And merge the results together.

The "stack" was the wrong thing to do. I think I would have undo pick a name like undo-1, undo-2 etc. Or something like that. redo would pick the most recent unless told to do otherwise.

A possible advantage of undo is having the freedom to stay on the current branch or switch to another.

Show 10 quoted lines
> Of course, right now we don't have a "delete branch" command, but it's 
> really as simple as
>
> 	rm .git/refs/heads/branchname
> 
> (and eventually you may want to do a "git prune" to get rid of stale
> objects, but that's a separate issue).
> 
> 		Linus
> 

This brings up a good point (indirectly). "git prune" would destroy the undo objects. I had thought of this but decided to ignore it for the time being.

Carl
-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl Baldwin                        Systems VLSI Laboratory
 Hewlett Packard Company
 MS 88                               work: 970 898-1523
 3404 E. Harmony Rd.                 work: Carl.N.Baldwin@hp.com
 Fort Collins, CO 80525              home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Previous: Linus TorvaldsNext: Daniel Barkalow
Message 4 of 21 in “[RFC] undo and redo”
  1. Carl BaldwinAug 24, 2005
  2. Carl BaldwinAug 24, 2005
  3. Linus TorvaldsAug 24, 2005
  4. Carl BaldwinAug 24, 2005
  5. Daniel BarkalowAug 24, 2005
  6. Carl BaldwinAug 24, 2005
  7. Daniel BarkalowAug 24, 2005
  8. Junio C HamanoAug 24, 2005
  9. Carl BaldwinAug 25, 2005
  10. Junio C HamanoAug 25, 2005
  11. Carl BaldwinAug 25, 2005
  12. Kalle ValoAug 25, 2005
  13. Kirby C. BohlingAug 25, 2005
  14. Junio C HamanoAug 25, 2005
  15. Kirby C. BohlingAug 25, 2005
  16. Carl BaldwinAug 25, 2005
  17. Carl BaldwinAug 25, 2005
  18. Kirby C. BohlingAug 25, 2005
  19. Carl BaldwinAug 25, 2005
  20. Junio C HamanoAug 24, 2005
  21. Carl BaldwinAug 24, 2005

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.