Difference between revisions of "Darcs vs. Git"

From HaskellWiki
Jump to navigation Jump to search
(push, pull, branch)
(Added context for GHC's switch from darcs to git)
 
(14 intermediate revisions by 4 users not shown)
Line 1: Line 1:
  +
= Darcs Resources =
I don't understand why so many people move from darcs to git.
 
   
== darcs replace ==
+
* http://darcs.net/ Main site
   
  +
* http://darcs.net/FAQ
Darcs can replace identifiers, Git cannot.
 
I often rename identifiers.
 
The identifier substitution of Darcs both saves space
 
and allows for smooth merging.
 
In Git renamings of identifiers look like you alter a lot of lines here and there.
 
I don't think that Git can easily implement that feature,
 
because it has no notion of a patch.
 
   
  +
* http://www.haskell.org/haskellwiki/Darcs
== darcs check --test ==
 
   
  +
* http://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory_and_conflicts
Darcs lets you easily run a test suite after every commit.
 
Usually I register
 
   
  +
= Git resources =
: <code>cabal configure && cabal build && cabal haddock && cabal test</code>
 
   
  +
* http://git-scm.com/ Main site
as a darcs test.
 
After recording a patch,
 
darcs unpacks the repository temporarily in the state after adding the patch.
 
Then it runs the test suite within that temporary copy of the repository.
 
If you add a file the Cabal description but forgot <code>darcs add</code>
 
or vice versa, then the darcs test will quickly spot the problem.
 
   
  +
* http://git-scm.com/book
This almost not possible with Git.
 
It could certainly be hacked into <code>.git/hooks/pre-commit.sample</code>,
 
but the crucial feature of running a test
 
is to reject a commit if it does not pass the tests.
 
If there is a way in Git then it is by far more complicated than in Darcs.
 
   
  +
* http://gitref.org/
I see no reason why Git does not support pre-commit tests properly.
 
   
  +
* http://bramcohen.livejournal.com/74462.html
== Pushing to the wrong repository ==
 
   
It is very easy in Git to push commits
+
= GHC's switch from darcs to git =
to an unrelated repository or to the wrong branch of a repository.
 
And it is cumbersome and dangerous to get rid of the wrongly pushed commits,
 
if operating in a bare remote git repository.
 
In a bare git repository you cannot use commands like 'git branch'
 
that you are familiar with in a working copy.
 
In darcs this cannot happen so easily
 
since normally darcs asks you which patch to push.
 
This way you can see early if something gets wrong.
 
   
  +
* http://www.haskell.org/pipermail/glasgow-haskell-users/2011-January/019752.html
== Pushing to repositories with working files ==
 
   
  +
* http://www.reddit.com/r/haskell/comments/ezgvs/rfc_migrating_ghc_development_to_git/ interesting thread
Pushing to a bare Git repository requires that you enable
 
the <code>post-update</code> hook. Why?
 
Pushing to a Git repository with working files is even more cumbersome.
 
I like to point people to certain files in a remote repository,
 
e.g. by an HTTP URL.
 
This requires automatic updates of working copy files when pushing to the remote repository.
 
If you try to push to a Git repository with working files
 
that is not prepared for this action
 
then you get a message that it is not possible
 
and what alternatives you have.
 
Among the alternatives there does not seem to be one
 
that automatically updates working copy files after a push.
 
Maybe it is possible in Git, but it requires at least some effort.
 
 
In darcs there is no distinction between bare repositories and working copies.
 
Working files are always automatically updated.
 
 
== Pull and stash ==
 
 
I often have locally modified files when pulling patches from somewhere else.
 
With git this needs at least three steps:
 
<code>
 
git stash
 
git pull
 
git stash pop
 
</code>
 
With darcs it is just <code>darcs pull</code>.
 
Git does not make backup files if there is a merge conflict, Darcs does.
 
 
== Branches ==
 
 
When working with Darcs I missed branches.
 
I thought it would be a good idea
 
to let the versioning system manage my attempts to solve hard problems in my projects.
 
I expected that if people clone my repository or pull patches
 
that they access all branches of my repository simultaneously.
 
I hoped that native support for branches
 
would be better than creating a new working copy for every branch.
 
 
Maybe Git got branching wrong
 
but today I am uncertain whether there is a good way to support branching
 
other than not supporting branching.
 
Git does not handle all branches of a repository simultaneously.
 
Git can push and pull commits from one local branch to another remote branch and back.
 
 
It is not so simple in Git to switch a branch if there are local modifications.
 
You need to <code>git stash</code>.
 
And what about the open text editor
 
that contains a file that gets modified by switching a branch?
 
Sure, modern text editors warn about changes on the file storage
 
but it is still easy to accidentally overwrite a file on one branch
 
with the contents of that file on another branch.
 
 
What I actually ended up is to create one Git working copy for every branch.
 
This way, switching between branches is easy.
 
This is precisely the way I work with Darcs.
 
 
 
== GitHub ==
 
 
github sucks, looping scripts, pull requests, how to get a git repository
 
 
 
== Merging ==
 

Latest revision as of 18:50, 18 June 2014