Shall I record this change? (1/?) [ynWsfqadjkc], or ? for help:I’ve rendered in bold the scary bit. I know that a prompt string like this is asking me to choose one of several single-character options. Normally, that’s fine; but in this case, yow! I have almost half the alphabet to choose from! Am I supposed to remember what the alphabet soup that isn’t “y” or “n” is for? And if I’m not expected to remember them, then why am I being prompted with them? Are they all equally important? And there’s still one more, truly obnoxious, piece of behaviour here. Unlike every other command line tool I’ve used in, well, as long as I can remember, darcs puts my terminal window into “cbreak” mode. What this means is that it responds immediately to a single keystroke, instead of waiting for me to hit the “return” key. Since every other tool that I use expects a keystroke followed by “return” when it prompts me in this way, that is how my muscle memory is trained: I type a key, I hit “return”. The result is that darcs treats what I intended to be one response as two—as responses to requests for handling two different hunks. The first hunk is handled however I specified, and darcs interprets the second as “do whatever the default action is on this hunk”. Ugh. There’s one final thing about darcs record. When I’m done foontling about with hunks, it asks me “What is the patch name?” Being an open source hacker, I associate “patch name” with “the name of a patch file”, but once again I must translate peculiar darcs idiom into familiar revision control language: darcs really wants a one-line description of my change, not a file name. So that’s the “record” command (I have similar gripes with several other darcs commands, but let’s keep this thing short). These aren’t fatal problems (for the fatal problem with darcs, see question 1 in the darcs FAQ), but I find these behaviours to be weird and annoying at least; in the case of the terminal-diddling business, downright bad. Long-time darcs users have no doubt trained themselves to not notice this stuff; I suppose I’ll get there eventually.
First impressions of darcs: not so hot
I’ve been using darcs recently for some Haskell-related revision control tasks, as it’s the revision control tool of choice for the Haskell community (no surprise; it’s the most widely used Haskell program in existence).
However, I can’t say I’ve been all that happy with darcs during my first few days of use. It has some behaviours that I think of as ill-considered, and not oriented towards making new users comfortable quickly.
By default, “darcs record” (the equivalent of “commit” in other tools—why the different command name?) prompts me for every single hunk, to see if I really want to commit that hunk. The “–all” option records all hunks, but why is this not the default? It’s all very well that I can pick and choose hunks, but why isn’t by far the most frequent use case embodied in the default behaviour of the command?
When I run “darcs record” without “–all”, darcs presents me with a prompt that is impressive in its opacity.
Posted in scm
11 comments on “First impressions of darcs: not so hot”
1 Pings/Trackbacks for "First impressions of darcs: not so hot"
-
[…] First impressions of darcs: not so hot […]
In my experience, recording only some of the changes made *is* the most frequent use case for darcs record. When I hack on something, I frequently make “side-hacks”, fix a bug or something, and I want to record them as separate from the main hack. Darcs lets me do that.
IIRC, you’re an emacs user… try ‘darcsum’ for recording, it’s just way way better than the command line.
http://darcs.net/DarcsWiki/DarcsumMode
The title is misleading. When I read “not so hot” I’m expecting startling new revelations–but these are cosmetic nitpicks!
Pretty weak complaints really. I don’t want to sound harsh but it seems like you are just trying to use darcs like what-ever you used before it. This would be missing a huge number of points.
Lets take interactive commits for instance. You complain about having to say yes to every commit… but why don’t you ask the following questions:
1) Have you ever written something but only after adding some scaffolding or debugging code? Do you really want that code in there?
2) Has one bug made you aware of another? Fixing two things in one tangled patch seems wrong. You should fix them but use record to track them appropriately.
3) Have you ever made some important changes and then forgot about a few of the unimportant whitespace changes that you made? Do you wish you could just avoid committing all that?
4) Is it really that easy to read through larger diff output than a case by case basis? Shouldn’t you give a careful check to things as you read over things in interactive mode?
5) Have you ever thought “oops” I forgot that change was in there… abort commit, edit, and start commit again? Why not just avoid the change and handle that other part after (with revert, ammend-record, etc…)
6) Do you really commit often enough? I usually have extremely small changes that can easily be tracked and managed. This means darcs rec is very quick and there are very few y’s.
7) Did you know you can incrementally build patches with ammend-record? This is a great tool to sort things out. It would be much less valuable if you had to write the changes in separate branches. I commonly create a parallel debug patch for some code so I can move it in and out quickly when and where it is needed for a certain bug.
8) Has a friend/co-worker/other person ever asked you for a quick change, yet you were in the middle of a big change and didn’t want to make a branch _just_ to do a one liner or typo fix? Quick interactive commits avoid changes that might be in the same file.
9) Conflicts are hard to avoid sometimes but when you can see the hunks separately it can really help to see what the dependent areas are. When I am cooperatively coding with a team it has been nice to be able to proactively be aware of what my footprint is so I know when to warn about certain lines or areas that a someone else might be working on. (I commonly play a patch ping-pong with someone else… this really helps a lot).
10)alias commit=darcs rec -a is simple enough if none of the above suite you.
… yes … I admit that interactive commits is one of the main reasons I use darcs. There are many more things that could be brought up as well.
Really… I think it might take some serious experimenting on your part before I would let a blog entry like this pass as a good beginner review.
Ok. Now for the positive side. At least you are one of the few who has the guts to not only try something new but you also are willing to gripe about things you don’t quite like yet. Give it some time and it might come to you… otherwise there are some other great SCMs out there like mercurial or different git setups (just don’t get stuck with the cvs/svn mind-set).
Since someone posted this to reddit, I’ll follow up to comments #3 and #4 above. Yes, I was picking nits! It’s true! These default behaviours of darcs struck me as annoying immediately, and that’s significant to me. If I’m designing a user interface, I strive for the first impression I give not to be off-putting.
I have objections to the underpinnings of darcs’s patch theory, too, but those are for a different posting.
Prompting for each hunk is one of the biggest advantages with darcs. Very rarely do I want to record all my changes in the same hunk. And if I do, there’s a key for that too. Just use ?, it’s your friend.
What darcs really needs is configurable defaults.
Interactive commit is good where the emphasis is on maintenance and bug tracking. It’s hell if you’re rapid-prototyping, though. My big problem was that I could never remember to commit at the right times when I was hacking something up, trying out options. And spending my neurons on remembering to commit made the Zone less accessible. My solution – to train myself to think aloud about my code: http://www.cs.utexas.edu/~akkartik/feed.cgi?codelog.html
“Have you ever written something but only after adding some scaffolding or debugging code? Do you really want that code in there?”
Again, it depends. If it’s just a private repo I care more about maintaining a record of the sequence of events rather than patch hygiene.
The amend-record trick is a good one, though.
Concise restatement: Cherry-picking while rapid-prototyping interferes with [flow](http://en.wikipedia.org/wiki/Flow_(psychology)). The more frequently you commit the greater the interference. The solution is not to avoid committing altogether; you do want a record of your trajectory so you can go over it when you come up for breath.
Addenda:
1. darcs does have programmable defaults:
http://programming.reddit.com/info/yq1t/comments/cyve8?context=5&style=nested#cyve8
2. Maintenance vs prototype programming has some mapping with [stevey’s notions of hardware and software](http://steve-yegge.blogspot.com/2007/01/pinocchio-problem.html) and with [the packer-mapper dichotomy](http://www.reciprocality.org/Reciprocality/r0).
Kartik,
Darcs does have configurable defaults. They are documented in the manual:
http://www.darcs.net/manual/node5.html#SECTION00510010000000000000
If you want “darcs record –all” to be the default behavior for you, it can be.
Hello Brian. Thanks for the note about darcs. (I noticed it via ‘http://planet.revisioncontrol.net/’.)
You wrote
“Long-time darcs users have no doubt trained themselves to not notice this stuff.”
but on the contrary every one of the five behaviours you objected to are behaviours that I explicitly like and that I consciously prefer over the alternative behaviours of other revision control tools. I think most long-time darcs users feel similarly about them.
For the record, that’s:
1. “darcs record” instead of “darcs commit”
This terminological distinction is important because running darcs record is *not* committing you to anything and does not expose your team-mates to the consequences of your work. This is a fundamental difference in workflow which is generally prefered by darcs users. A few times I’ve observed people misunderstanding darcs workflow by thinking that “darcs record” is like “svn commit”.
2. “–all” is not the default
This default setting is valuable because the common case for long-time darcs users is to choose only a subset of edits to batch together into one darcs patch. This is a change in workflow which is much beloved by almost all long-time darcs users — it means you can opportunistically make an unrelated change as you are working on a different change and then sort them into logical patches later.
3. many features available by keystroke at the interactive prompt
I really like this behaviour. When I started out with darcs I used only four or five of the options, but over time I’ve learned more and more of them and I enjoy the convenience and power they offer.
4. cbreak mode
I prefer this. Darcs on Windows does not have the ability to do this, so I use both cbreak and non-cbreak darcs every day, and I know which one I prefer.
5. “patch name” is an arbitrary length, arbitrary content, human readable string instead of a more restricted format
I prefer this, but perhaps it would be nice if it were called something other than “name”, in order to allay the irritation that many including you have experienced.
Regards,
Zooko,
long-time darcs user
Well, it took us 3.5 years to address the scary interactive prompt, but we finally got there. We just applied a patch that changes the prompt to only display “basic” characters, while leaving a few clues for potential power users to explore:
Before: Shall I record this change? (1/8) [ynWesfvplxdaqjk], or ? for help:
After: Shall I record this change? (1/8) [ynW…], or ? for more options:
Darcs 2.5 and up should be a little bit friendlier. Thanks for the UI bug!