[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] [PATCH] tla revert
From: |
Miles Bader |
Subject: |
Re: [Gnu-arch-users] [PATCH] tla revert |
Date: |
Sat, 6 Sep 2003 21:30:26 -0400 |
User-agent: |
Mutt/1.3.28i |
On Sun, Sep 07, 2003 at 01:54:29AM +0100, Bruce Stephens wrote:
> > Regarding this particular change: I wonder if it wouldn't be better
> > to add support for limited-scope undo to the `undo' command
> > (analogous to the '[-- file ...]' optional arguments to `commit')?
>
> Maybe, but that seems overkill for many situations. I imagine revert
> is intended for when you decide that what you've done to the file just
> isn't worth saving, and you want to forget all the changes. undo
> seems to have a broader role.
I disagree, undo seems almost perfect for this. If it could be restricted
to a certain file(s), it would have exactly the desired effect -- and has
the further advantage of later being redoable if you realize those changes
were desirable after all (some people might complain about the ,,undo-N
droppings, but they're easy enough to delete; I tend to leave them sitting
around until I've finished whatever task I'm working on, Just In Case).
> On the other hand, perhaps it's better to optimize certain uses of undo
> (where you don't want it to record the changeset).
I think a general concept of a `tree limit', which would restrict whatever
operation to a subtree, would be very useful in arch anyway... (don't know
how this stuff is handled currently)
[Even beyond user-visible uses: for instance, if you do a star-merge it
currently checks out 2 copies of the whole tree, which could be very
inefficient for large trees; what if it could instead say `tell me all the
files/changesets that are effected by these changesets', and then restrict
what it checks out to that subset ...?]
-Miles
--
I'd rather be consing.
Undo of individual files (was Re: [Gnu-arch-users] [PATCH] tla revert), Momchil Velikov, 2003/09/07