08:42 am, 5 Jan 10
your vcs sucks
I've been hacking on some Haskell stuff lately that's all managed in darcs and it's reminded me of an observation I made over two years ago now (see last paragraph), which is roughly: git is used widely enough that to get pretty much anything done with free software today you'll end up using git somewhere. So if your project doesn't use git, that means I get to learn git and whatever it is your project uses. (This issue comes up a lot for me, so much that a story about it is one of the few non-technical things I host on my website.)
I used to use darcs a lot. I get it, it's different, it's got some cool mathematical models and UI stuff, git's UI is terrible. I maintain it's not different enough from git to really matter.
And now I have to dig through manpages whenever I want to figure out trivial stuff like "did I forget to add any files in this commit?" (that's
I'm especially looking at you, bzr users: you have no excuse. At least darcs is trying a different approach to how patches are managed! As far as I can tell bzr is "like the other ones, but slower".
I used to use darcs a lot. I get it, it's different, it's got some cool mathematical models and UI stuff, git's UI is terrible. I maintain it's not different enough from git to really matter.
And now I have to dig through manpages whenever I want to figure out trivial stuff like "did I forget to add any files in this commit?" (that's
darcs whatsnew --look-for-adds) or "what files are in the repo?" (I recall using some sort of "inventory" command but after a lot of poking around it appears to be darcs show files -- tricky, putting it in a subcommand).I'm especially looking at you, bzr users: you have no excuse. At least darcs is trying a different approach to how patches are managed! As far as I can tell bzr is "like the other ones, but slower".
Anyway, I take this post as evidence that you have successfully repressed tla.
I'm kind of resigned to having to be familiar with Git and SVN as well. Just another aspect of the multilingualism that's required for keeping up with CS.
Staging is useful
Here's the problem with the staging-is-weird argument: I use staging all the time. It's useful. Yes, there's an up-front learning cost, but it's small, and after you've paid it, it's all gravy. (And gravy is good.)Cheers,
Tom
Re: Staging is useful
I'm glad there's someone out there (besides Linus, presumably) who finds staging useful; you're the first one I've heard from. I've been using it for a month now (after a decade-plus on other VCSs) and it still seems like just an annoyance to me.Based on that low ratio (admittedly a totally unscientific survey) it would have been nice to make it an optional feature or extension or something.
Re: Staging is useful
I use it every day. Heck, I use 'git add --patch' all the time to stage not just individual files, but individual changes within individual files.(`git add -u' stages all changes in all modified files and `git commit -a' stages and commits all changes in all modified files, incidentally.)
Re: Staging is useful
FWIW, I love staging too.I use it all the time and can’t currently imagine moving to any other VCS precisely because no other VCS at this time has this concept.
The key to understanding what staging is good for is how it interacts with
git diff. Once you add something to the index, it disappears off the diff. This is hugely helpful.It means that eg. when a merge fails, the part of the merge that was successful does not cloud the diff, and as you resolve conflicts and
git addthem, they too disappear from the diff. Maybe this is why Linus introduced the concept in the first place, being that his job is mainly to perform merges all day long. But that’s far from the only circumstance in which the index has been useful to me.Often, when I set out to make some self-contained change to the code, I don’t know up front the detailed approach of how I’ll go about it. I also often end up making incidental other changes – a small improvement to the tag library, a fix for a tiny bug I noticed while tooling about in the vicinity, stuff like that. Also, I sometimes end up changing directions a few times for some aspect or other of the change that I was originally planning to make.
With the index, I just keep working for however long I need to. Afterwards, I start by reviewing the diff to see how to break down the work into chunks that will make sense to whoever might read the patches later. Then I gradually use
git add --patchto untangle changes from each other into separate logical steps. Occasionally I even go in and edit the diff to pull apart changes that affect the same lines. Now,git diffbecomes “work I haven’t reviewed yet” andgit diff --cachedbecause “work I have vetted for inclusion in the logical step I am building up”.I’d say I end up making about 3-and-change commits on average out of non-trivial work units.
(And yes, I run the tests on each commit separately to see if what I’m checking compiles and makes sense. A neat tool I recently discovered is
git stash --keep-index, which will stash away everything you see ingit diffand leave the working copy as an identical copy of the index. This makes it easy to run the tests before committing. Then yougit stash popand keep going as usual. Extremely handy.)Mind you, when I first heard about the index, I thought it was silly, and when I heard how
git diffinteracts with it, to me it sounded outright stupid. Why would anyone want that?! Now I can’t live without it.bzr projects end up with a stream of consciousness style merge history. I find it maddening. Also launchpad's sluggishness is maddening.
http://skitch.com/jasonrudolph/nphe8/checking-out-remote-branches-in-git-1.6.6
“Then don’t use it.”
If that’s really all the bzr crowd have going for it, their air sure seems to be getting thin…
Darcs rosetta stone page
Hi Evan,Does our Rosetta Stone (http://wiki.darcs.net/RosettaStone) wiki page help in any way (or would it have helped in principle, at least?).
I'm really pleased to see you agree that Darcs is really trying something different. Over time, Darcs needs to grow a marketing machine that can very skillfully explain why these differences are compelling, how Darcs can make your life easier. In time, though... in time...
Meanwhile, we have to keep hacking away at it, solving the many performance problems one by one. If we could just keep sucking a little less one release at a time, we could maybe one day have the last laugh :-)
I'll leave you with one of my favourite Darcs quotes:
Re: Darcs rosetta stone page
I am glad you are considering other systems; it would have saved me a lot of time if "commit" and "status" would do what they do elsewhere.I think when you use a system for a while it seems simple. Trying to do "simple" stuff with darcs for me is very hard because git is simple for me (and I could write a similar quote about the conceptual purity of git as what Taylor did about darcs). Here are some of the sorts of things that are simple in git I couldn't figure out:
- check out the state of the world two commits back to see if it worked then
- show diffs between arbitrary points in the commit history (e.g. "what did those two patches I did last week introduce?" or "what have I done here that isn't yet upstream?")
Anyway, in practice I think what would help you the most is lowering the impedance mismatch. Sometimes now I occasionally have to deal with bzr repos too but even they are easier to figure out than darcs ones.
Re: Darcs rosetta stone page
In case this is useful for the future, to check out the state of the world two commits back,darcs get repo two-commits-back
cd two-commits-back; darcs unpull --last=2
Yeah, that is clunky. One easy fix would be to add the --last flag to get (as you can currently do things like darcs get repo --tag 0.2.4; which works on the same principles).
To show diffs between arbitrary points in history, you can diff --from-patch X --to-patch Y. There is also a diff --index which does exactly what you want, but is currently broken (http://bugs.darcs.net/issue1290) :-( [I realise this is somewhat cheeky for me to say, but we'd be very grateful for a patch; I'm sure it wouldn't be hard for you].
Also, if you ever get around to hacking on that Haskell git implementation again (and I hope you do), you may be interested in the hashed-storage library. Right now, it's just an improved implementation of the hashed storage stuff that Darcs uses, but there's no reason why it couldn't also include git-style hashed-storage, I imagine.