4 ms·

> It's absolutely relevant. Git needs the "rebase" command to stitch independent histories together; Darcs doesn't. That's the part I don't get from your argum

by rualca 6y ago

> It's absolutely relevant. Git needs the "rebase" command to stitch independent histories together; Darcs doesn't. That's the part I don't get from your argument. Git has rebase. It works. So where exactly do you see the value added by Darcs? I mean, it's not as if users can only merge or rebase if they use Darcs, right? > As for workflows that "require any of those properties": There's wide agreement that Git is overly complex (...) No, there isn't. In fact, that statement is patently false. git is the simplest and most straight-forward version control system I ever used. Things just work out of the box, they work well, and they work exceptionally fast. Branching is free, merging is free, tagging is free, it's trivial to checkout, it's trivial to setup a shared remote repository, and it's even trivial to setup a remote repo on a USB pen. You don't need to install servers to get it to work locally or remotely, you don't need to bother with extensions to get basic functionality working, and you don't need to use absurd ad-hoc patterns to get basic features such as branching. So is there actually any objective point that can be made in favour of Darcs? I mean, being fast and usable surely is not it. So, what real-world value does Darcs offer?

atombender 6y ago
Rebasing rewrites history, and Git's strict linear histories mean you can no longer push or easily resolve conflicting histories (see: "git rerere") that have diverged. With Darcs, you can. You can merge/cherry-pick any history without incurring other conflicts than "real" conflicts where people have worked on the same lines of text. This eliminates a large group of commands Git has to provide ("rebase", "cherry-pick", "rerere", "reset", etc.) because the entire problem space doesn't even exist. Darcs is utterly magical that way. > No, there isn't. I have to disagree there. There's a huge corpus of material showing that people struggle with Git. For example, a cursory search of HN shows many, many threads that devolve into discussions about how unnecessarily complicated and complex Git is. You can also go on Stack Overflow or other forums and look at all the users whose repositories are stuck in a state they don't understand. I suspect no other VCS has forced so many users to give up and wipe their local repo to start over again. Git's UI has gotten better over the years since I started using it around 2007, but it's not great at explaining repository state. Many less-than-technical people — such as designers — have been forced into using Git as part of their work. Subversion was extremely popular in this group, and the transition to Git was slow precisely because Subversion offered simplicity where Git didn't. Anecdotally, I work with a bunch of highly competent, highly technical colleagues — some of whom I consider to be better developers than myself — who still sometimes struggle working with Git. Most developers don't want, I think, to be "Git experts"; they just want to get stuff done. Most users, myself included, arguably use just a tiny subset of Git commands that deal with the daily pull/push/commit workflow. When I joined my current company, people weren't even practicing clean histories, but using "git merge". But once you get into rebasing (which many people do not do) and diverging histories across multiple levels of branches, you open a whole can of worms that Git is not good at dealing with. Rerere, while a huge time-saver, doesn't solve everything in such complicated scenarios. Perhaps you're perfectly fine with all of this, but in that case you are not representative of the average user, in my opinion. > git is the simplest and most straight-forward version control system I ever used Since I started out, I've used RCS, Visual SourceSafe, CVS, Subversion, Perforce, GNU Arch, Darcs, and Mercurial. The only tool more complex than Git was GNU Arch (though, admittedly, required jumping through some ridiculous hoops to work around its lack of native branching support), but Git is without question the most complicated and complex that has been in mainstream use.

by rualca 6y ago

atombender 6y ago

Rebasing rewrites history, and Git's strict linear histories mean you can no longer push or easily resolve conflicting histories (see: "git rerere") that have diverged. With Darcs, you can. You can merge/cherry-pick any history without incurring other conflicts than "real" conflicts where people have worked on the same lines of text. This eliminates a large group of commands Git has to provide ("rebase", "cherry-pick", "rerere", "reset", etc.) because the entire problem space doesn't even exist. Darcs is utterly magical that way. > No, there isn't. I have to disagree there. There's a huge corpus of material showing that people struggle with Git. For example, a cursory search of HN shows many, many threads that devolve into discussions about how unnecessarily complicated and complex Git is. You can also go on Stack Overflow or other forums and look at all the users whose repositories are stuck in a state they don't understand. I suspect no other VCS has forced so many users to give up and wipe their local repo to start over again. Git's UI has gotten better over the years since I started using it around 2007, but it's not great at explaining repository state. Many less-than-technical people — such as designers — have been forced into using Git as part of their work. Subversion was extremely popular in this group, and the transition to Git was slow precisely because Subversion offered simplicity where Git didn't. Anecdotally, I work with a bunch of highly competent, highly technical colleagues — some of whom I consider to be better developers than myself — who still sometimes struggle working with Git. Most developers don't want, I think, to be "Git experts"; they just want to get stuff done. Most users, myself included, arguably use just a tiny subset of Git commands that deal with the daily pull/push/commit workflow. When I joined my current company, people weren't even practicing clean histories, but using "git merge". But once you get into rebasing (which many people do not do) and diverging histories across multiple levels of branches, you open a whole can of worms that Git is not good at dealing with. Rerere, while a huge time-saver, doesn't solve everything in such complicated scenarios. Perhaps you're perfectly fine with all of this, but in that case you are not representative of the average user, in my opinion. > git is the simplest and most straight-forward version control system I ever used Since I started out, I've used RCS, Visual SourceSafe, CVS, Subversion, Perforce, GNU Arch, Darcs, and Mercurial. The only tool more complex than Git was GNU Arch (though, admittedly, required jumping through some ridiculous hoops to work around its lack of native branching support), but Git is without question the most complicated and complex that has been in mainstream use.