Git sucks, or why do I use darcs instead | Hacker News Reader

Git sucks, or why do I use darcs instead

komar.in

25 pointsdmmalam21 comments

I started using DCVSes with darcs and liked it quite a bit — a real breath of fresh air compared to the nastiness of cvs and svn. Nice UI overall. Unfortunately, it had a nasty bug where commits or merges would hang indefinitely. It was a hole in the theory of patches, I believe. The bug took forever to fix (over a year, if memory serves), and darcs lost momentum to Git, which worked much faster and more reliably (and has extra really nice features like the svn bridge).

Not a git guru by any stretch of the imagination, but:

Interactive mode: "git add -p" ?

Reverting commits: "git revert commit-id" ?

Code sharing: Pretty sure git supports cloning from straight http:// (or even a file:/// if you have a smb share or whatever) ?

Git supports cloning over http, ssh, local file path. You can also create patch sets with `git diff` and share them however you want, obviously including email.

You can also mess with what you merge and what not via `git rebase -i` and `git cherry-pick`.

I don't see anything where darcs would be superior to git. It's just a matter of taste. Nothing to see here.

This scares me a bit because of what they're doing to essentially drop dependency information that's preserved in normal git commit order.

If you ignore commit order, individual lines have no way of really conveying what they've been tested with, nor what they will break if added or omitted, independent of commit time.

You get a lot of that stored automatically with git, by forcing people to define changes in terms of what was there before the change takes place.

You also have the ability to reposition this information with git rebase, and to safely walk it through change conflicts to make sure you affirm what is happening.

With this in mind, I think an algorithm like darcs' history looks like it would be much more suitable in text/block based editing, rather than programming. Something like tracking history in XML or following a Microsoft Word document.

Absolutely, even over-eager use of "git add -p" can easily create commit "snapshots" that won't actually compile.

I used darcs years ago before switching to git. I liked it a lot, but git had more support/momentum so we switched. Camp looks interesting but also seems dead based on the mailing list archives.

This is the same reason we switched from darcs to git. The value of ubiquity exceeded the value of our previous preferences.

I had never heard of darcs before, but it sounds pretty interesting:

"Darcs is a distributed revision control system... Key features include the ability to choose which changes to accept from other repositories, interaction with either other local (on-disk) repositories or remote repositories via SSH, HTTP, or email, and an unusually interactive interface. The developers also emphasize the use of advanced software tools for verifying correctness: the expressive type system of the functional programming language Haskell enforces some properties, and randomized testing via QuickCheck verifies many others."[1]

[1] https://en.wikipedia.org/wiki/Darcs

It is pretty interesting because it's one of the first popular DCVS systems. It's also an interesting case study in how you can be so right and yet so wrong at the same time, failing to capture any meaningful market share, while others like git steamrollered it.

If you want to revert a file in git, you are not reverting the file. Reverts are attached to commits.

Instead, you are restoring a file to its previous state. To do this:

git checkout <commit> -- path/to/file

> Code sharing sucks

gitweb? cgit? Also, why does codesharing require HTTP?

Otherwise a surprisingly non-ragey post for someone who is comparing the pros and cons of a tool that is obviously very important to OP.

"Digital sucks, or why I use cassette tapes instead."

Seriously, if your complaints about git are a few implementation problems, user interface, and that some commands are needlessly complicated, your solution should not be to use a completely different revision control system used by nobody.

How about "DARCS did some things right that git could learn from" as a different way to present this material?

>How about "DARCS did some things right that git could learn from" as a different way to present this material?

git could not switch from their history centric model to darcs' patch centric model and fix the schizophrenic ui without breaking everything built around git. In such a case a different project is useful. See python2 vs python3.

This comment is interesting:

  The only haskell thing that works good is xmonad. I used it for years and still very happy with it.
  The only haskell things that works fast are qsort and shootout tests.
  The other haskell soft is full of shit and I can't understand why.

Is this just editorializing or is there some truth to this?

I usually do 'git checkout <branch/tag/sha_of_commit> -- <filename>' to revert a single file to previous state. If I ever need a gui (very, very rare), I would just use 'gitk'. Small and does the work.

The video example had features and bug fixes in the same branch. It would have been more idiomatic for git to create separate branches, which would have shown it to be just as flexible.

darcs was the first DVCs I used, back in 2006. Coming from Subversion, I felt that its command line UI just plain beautiful. Since then I've moved on to mercurial, because most of the other people on my team wanted to use hg and then subsequently git, when I changed jobs. It looks like we're moving towards more and more brittle command line interfaces rather than simpler, cleaner and more polished ones.

I use darcs for everything, i pretend to use git and github by using a tool called darcs-to-git :-)

why?

I'm surprised that there is no command "git sucks" in git.

it's easy to add custom commands to git

Reply on news.ycombinator.com