[darcs-users] How to avoid extra "last regrets" question?

Benjamin Franksen benjamin.franksen at helmholtz-berlin.de
Wed Jul 3 16:56:22 UTC 2013


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




More information about the darcs-users mailing list