Re: [RFC] undo and redo

On Thu, Aug 25, 2005 at 02:37:33PM -0600, Carl Baldwin wrote:

On Thu, Aug 25, 2005 at 02:59:18PM -0500, Kirby C. Bohling wrote:

quoted

On Thu, Aug 25, 2005 at 10:32:01AM -0600, Carl Baldwin wrote:
<snip...>

quoted

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.

I used to do this with CVS too.  For you and me, people who are patch
savy veterans, this is great!  However, as easy as it is I knew very few
other developers who even thought about doing it.  In the real world,
many people see a huge difference between:

git diff-cache > $patchfile
cat $patchfile | patch -R -p1
do work
cat $patchfile | patch -p1

AND

git undo
do work
git redo

The first one simply never happens with most developers.  Most don't
really think of doing something outside the tool.  The second option
will likely get used.  Plus, I know at least one person here who is very
good with patches and working outside the tool and still would love to
have the second approach available.

I guess I can see that.  I just see it as much easier to manage
multiple undo-redo states manually.  I mean, I wouldn't make anyone
use git directly if the difference between the two commands bothers
them.  git seems too low a level.  I would think one of the
procelains would be be a better level.  However, having a unified
interface for all the porcelains seems a reasonable request.

Is there something wrong with having flexibility?  It seems most of the
criticism of this feature is that there is already a way to accomplish
what I want to do.  Tools that can't be used flexibly are not tools that
I like to use.  Heck, I'm on UNIX aren't I?

Oops, sorry for the rant.  I'm really not in a bad mood... really.  I
hope it didn't sound like that :-).  Oh, and I didn't mean to suggest
that git is not flexible in other regards.  I think its great!  Moving
along...

quoted

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 can simulate git manually too with just a few more commands.  Where's
the cutoff?

Yes and no.  I meant the order and style of commands was nearly
identical.  I meant applying the command line in reverse was the
only additional step.  As a workflow, I'd just document it in the
HOWTO's.  I'm a minimalist in that sense.  Sure, I use more then
echo, redirection and netcat even though in theory I could send you
this e-mail with it.  IMHO, the above undo/redo doesn't seem to save
enough effort to me.  I wouldn't bother learning undo/redo unless it
was superior to the patch way, it's just one more thing I'd have to
remember.

quoted

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.  

Not having to manually manage a set of patches may seem small but it
reduces a barrier that may otherwise be just high enough to hurt
productivity in certain situations.

I don't mean to discourge it's implementation, I really questioned
it because I figured there had to be some more subtle implications I
didn't understand about undo/redo that patch couldn't capture.  It
also seems like multiple levels of undo/redo or undo/redo on
multiple branches could get tricky for the user to track and for git
to be able to display the information to the user sanely.

    Thanks,
        Kirby