Re: [RFC] undo and redo

["Kirby C. Bohling" <kbohling@birddog.com>]

On Thu, Aug 25, 2005 at 10:32:01AM -0600, Carl Baldwin wrote:
<snip...>
> Another example is if I'm working on a commit and suddenly get a
> brilliant idea for some easy modification that I want to make and commit
> by itself before making this commit.  I can do this easily with
> 
>         % git undo
>         % carefully make easy change
>         % git commit
>         % git redo
> 
> Having a light-weight alternative like this could make the difference
> between realizing the easy, brilliant idea and forgetting about it on
> the back burner because it was just too cumbersome to make the context
> switch.
> 
> The bottom line is that I don't argue against using the existing
> work-flows.  I hope to add the flexibility to use various work-flows to
> fit the job at hand.
> 
<snip...>

[Not much of a git user, but am evaluating it for possible future
usage]... 

Why not just save the changes to a file via a patch.  Just like you
would if you were sending a patch to someone else.  I have the work
flow you are talking about when I use CVS.  I just create a patch,
apply the patch in reverse (or run the command to get you a clean
working tree in the SCM).  Make my unrelated changes commit it.
Then apply the patch, possibly resolve merge conflicts,  and proceed
with finishing my original work.

Assuming your patch creation and application tools capture all the
meta-data the SCM has (which I believe git does), it's pretty simple
to simulate what you want manaully.  With only a handful of
commands.

I see the appeal of not having manually deal with the files, but
assuming you don't feel it's branch worthy, and you don't want to
have it be something someone else can access externally, it doesn't
seem like a feature I can't get almost as simply with existing git
commands.  

I guess my final question is what does undo/redo have over saving
stuff away in a patch assuming that the patch captures all of the
SCM meta-data (the add/move/remove file type commands).  If git
doesn't capture all the meta-data in a patch, it would seem better
to make it do that and get this as a side-affect.

    Thanks,
        Kirby