From: Carl Baldwin <cnb@fc.hp.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Carl Baldwin <cnb@fc.hp.com>, git@vger.kernel.org
Subject: Re: [RFC] undo and redo
Date: Wed, 24 Aug 2005 13:56:15 -0600 [thread overview]
Message-ID: <20050824195615.GA693@hpsvcnb.fc.hp.com> (raw)
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:
>
>
> 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.
> 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.
> 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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
next prev parent reply other threads:[~2005-08-24 19:56 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-24 17:23 [RFC] undo and redo Carl Baldwin
2005-08-24 18:10 ` Carl Baldwin
2005-08-24 18:51 ` Linus Torvalds
2005-08-24 19:56 ` Carl Baldwin [this message]
2005-08-24 20:44 ` Daniel Barkalow
2005-08-24 20:47 ` Carl Baldwin
2005-08-24 21:04 ` Daniel Barkalow
2005-08-24 22:48 ` Junio C Hamano
2005-08-25 2:41 ` Carl Baldwin
2005-08-25 5:06 ` Junio C Hamano
2005-08-25 16:32 ` Carl Baldwin
2005-08-25 17:39 ` Kalle Valo
2005-08-25 19:59 ` Kirby C. Bohling
2005-08-25 20:19 ` Junio C Hamano
2005-08-25 20:49 ` Kirby C. Bohling
2005-08-25 21:28 ` Carl Baldwin
2005-08-25 20:37 ` Carl Baldwin
2005-08-25 21:09 ` Kirby C. Bohling
2005-08-25 21:42 ` Carl Baldwin
2005-08-24 18:18 ` Junio C Hamano
2005-08-24 20:01 ` Carl Baldwin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050824195615.GA693@hpsvcnb.fc.hp.com \
--to=cnb@fc.hp.com \
--cc=git@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.