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.
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]
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.
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.
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.
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).
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 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.
"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.
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?
21 comments
[ 3.2 ms ] story [ 55.5 ms ] threadInteractive 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) ?
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.
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.
"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
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.
Instead, you are restoring a file to its previous state. To do this:
git checkout <commit> -- path/to/file
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?
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.