
(subject changed for easy filtering of flamebait, removed libraries@)
On 7 October 2010 10:45, Jason Dagit
At the risk of starting a darcs vs. git discussion I have some thoughts about the tension.
On Wed, Oct 6, 2010 at 12:10 PM, Don Stewart
wrote: [snip] == GHC ==
* ghc status + 50% split in room on moving ghc from darcs to git.
I don't see that tension resolving itself easily. VCS tools are subject to "network effects". If your friends are using VCS Foo and you want to work with them, then you adopt Foo too. It's also a part of the toolchain that people tend to have strong opinions about.
One possible way to lessen the tension would be good vcs bridge tools. There have been numerous repo converter projects, some even supporting synchronization. There is already a git-svn tool. Maybe there should be a git-darcs (and a darcs-git)? If a git hacker out there wants to add darcs support to git, I'd certainly be willing to help them get started.
Pushing on this a bit more, I'm fairly convinced that darcs and git are dual to each other in terms of underlying models. As such, I have some ideas on how to unify them/convert between models. Unfortunately, actually having something to use is very far off as the ideas themselves are still immature.
As far as I can tell, the main reasons to vote for git: * Some people simply love git and want to use it for every project * Git is faster and/or more memory efficient for some operations (most? all?) * Github
As far as I can tell, the main reasons to vote for darcs: * GHC already uses it (inertia) * The windows support appears to be more mature (I admit, this is somewhat subjective as neither has a spotless record here) * Key players, such as the Simons, prefer the darcs UI over the git UI (i.e., some people prefer darcs) * Darcs 2.x has consistently improved in robustness and efficiency over the last several years, continues to improve, and incorporates ideas from git. (there is currently an experimental 'rebase' command in the development branch of darcs) * Cherry picking
Note: I didn't mention feature branches as a reason to prefer one over the other. Both darcs and git support this. Git uses in-repo branches and with darcs you can simply do a local lazy get. Some people prefer one mechanism over the other, but the point is they both support the workflow.
I hope they do :) With darcs, is it possible to refer to various other (local and remote) branch names, eg. to do diffs between branches? What I mean is that with git, I can do: $ git fetch origin $ git diff my-foo origin/random-bar to see changes between my local branch "my-branch-foo" and the remote branch "random-bar" without having to make an explicit checkout of origin/random-bar. When the origin repo contains many branches that other people are working on, this is a pretty neat way of keeping track of those. I'd really like to be able to get an overview of what branches are available (on my local copy and remotely), like with git's various graphing tools; I just use a "git log --graph" alias to get a tree view in the console: http://blog.kfish.org/2010/04/git-lola.html Does something similar exist for darcs?
I would like to see the tension of darcs vs git for GHC reduced. I think it ultimately amounts to: Contributors need to be able to use the one they prefer, instead of being forced to use the one GHC devs use.
I agree with that, and I don't mind switching between the two for different projects. Perhaps some standard subcommand aliases would go a long way to making that easier though (log vs. changes etc.) cheers, Conrad.

On Wed, Oct 6, 2010 at 7:42 PM, Conrad Parker
(subject changed for easy filtering of flamebait, removed libraries@)
On 7 October 2010 10:45, Jason Dagit
wrote: At the risk of starting a darcs vs. git discussion I have some thoughts about the tension.
On Wed, Oct 6, 2010 at 12:10 PM, Don Stewart
wrote: [snip] == GHC ==
* ghc status + 50% split in room on moving ghc from darcs to git.
I don't see that tension resolving itself easily. VCS tools are subject to "network effects". If your friends are using VCS Foo and you want to work with them, then you adopt Foo too. It's also a part of the toolchain that people tend to have strong opinions about.
One possible way to lessen the tension would be good vcs bridge tools. There have been numerous repo converter projects, some even supporting synchronization. There is already a git-svn tool. Maybe there should be a git-darcs (and a darcs-git)? If a git hacker out there wants to add darcs support to git, I'd certainly be willing to help them get started.
Pushing on this a bit more, I'm fairly convinced that darcs and git are dual to each other in terms of underlying models. As such, I have some ideas on how to unify them/convert between models. Unfortunately, actually having something to use is very far off as the ideas themselves are still immature.
As far as I can tell, the main reasons to vote for git: * Some people simply love git and want to use it for every project * Git is faster and/or more memory efficient for some operations (most? all?) * Github
As far as I can tell, the main reasons to vote for darcs: * GHC already uses it (inertia) * The windows support appears to be more mature (I admit, this is somewhat subjective as neither has a spotless record here) * Key players, such as the Simons, prefer the darcs UI over the git UI (i.e., some people prefer darcs) * Darcs 2.x has consistently improved in robustness and efficiency over the last several years, continues to improve, and incorporates ideas from git. (there is currently an experimental 'rebase' command in the development branch of darcs) * Cherry picking
Note: I didn't mention feature branches as a reason to prefer one over the other. Both darcs and git support this. Git uses in-repo branches and with darcs you can simply do a local lazy get. Some people prefer one mechanism over the other, but the point is they both support the workflow.
I hope they do :)
With darcs, is it possible to refer to various other (local and remote) branch names, eg. to do diffs between branches? What I mean is that with git, I can do:
$ git fetch origin $ git diff my-foo origin/random-bar
You can see the difference of the recorded changes using push or pull. If you want a read-only view, add --dry-run. $ darcs pull --dry-run http://foo.com/random-bar
to see changes between my local branch "my-branch-foo" and the remote branch "random-bar" without having to make an explicit checkout of origin/random-bar. When the origin repo contains many branches that other people are working on, this is a pretty neat way of keeping track of those.
I'd really like to be able to get an overview of what branches are available (on my local copy and remotely), like with git's various graphing tools; I just use a "git log --graph" alias to get a tree view in the console:
http://blog.kfish.org/2010/04/git-lola.html
Does something similar exist for darcs?
Yes and no. Because darcs chooses to keep each branch as a separate directory it doesn't have a notion that a change can have multiple children. Currently when you type 'darcs log' you do see the graph, it's just perfectly straight. What you might want to know is, when can a change come after some other change? Answering that question is computationally a bit inefficient. I think I heard someone suggest it is quadratic in the number of changes. You might like this video that demonstrates a proof of concept graphing tool like you're looking for: http://www.youtube.com/watch?v=iOGmwA5yBn0
I would like to see the tension of darcs vs git for GHC reduced. I think it ultimately amounts to: Contributors need to be able to use the one they prefer, instead of being forced to use the one GHC devs use.
I agree with that, and I don't mind switching between the two for different projects.
Perhaps some standard subcommand aliases would go a long way to making that easier though (log vs. changes etc.)
Done. Already supported in at least one released version :) In general, you might want to look here: http://wiki.darcs.net/RosettaStone Darcs has a fair number of undocumented command aliases to handle requests like yours. I hope that helps, Jason
participants (2)
-
Conrad Parker
-
Jason Dagit