Eric Kow wrote: > I like the general style of thinking below (thorough, careful, looking > at the *whole* picture).
Thanks :-) > I'm not sure destructiveness is really the decision basis, partly was > about ?aww, man, do I have to go through and make all my decisions > again??, Right, absolutely. It may not be as bad as deleting all the changes I made in my source tree (like e.g. revert does), but I did add important information to my tree making the selection (possibly editing a number of hunks on the way) and that should not be lost due to a stupid mistake. If (after making lots of decisions) I say "Yes, record these changes" I do not loose any information. So, with darcs record the default should be to err on the side of "yes, record please", not "no, better not". That is to say, for 'darcs record' it would make more sense (IMO) to offer the last regrets when the user hits the [q] button, and Darcs asked me: "Are you sure you don't want to record anything? You'll loose all the choices you made so far. [yN]". In order to get some structure into all the possibilities, I propose to classify commands into positive and negative ones: a positive command (like record) /adds/ information. Undoing its effect is simple, redoing after cancel or interrupt can be hard. Negative commands (like obliterate) /subtract/ information. Undoing their effect is hard, if not impossible. Redoing them after a cancel is easy. Commands like amend-(un)record don't seem to fit into this classification, though. While I do the selection, I create valuable information, but once I commit, I also destroy some. I would solve this by separating the two stages and acting according to which stage we're in: as long as we are in the positive stage we guard against accidentally cancelling the operation; however, when the user is about to commit, we guard against accidentally deciding to irreversibly update an existing patch. We can do even better: what I would **love** to have is Darcs saving my selection (including hunk edits), so that I can later continue where I left off. Even better, this need not be confined to a single command: when I make a selection out of a large number of hunks, say during a darcs amend-record, then decide against, I might later want to use the same selection but for a normal 'darcs record'. I also want to be able to incrementally add and/or remove atomic changes (hunks, etc) from such a selection. I think there is no other VCS out there that has such a feature built in. Once again Darcs could /set/ the trend instead of trying to catch up. Cheers -- Ben Franksen () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachm?nts _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
