Git Overview

The git "local repository" corresponds to darcs internal store of patches. The git "workspace" corresponds to your normal code tree in darcs. The git "index" is a staging area within the current repository, for storing partially-committed hunks. It has no equivalent in darcs.

darcs put

Note: If the repository is supposed to be shared by several users, it's best to init it with either of these commands:

git init --shared=group # everyone in the same group can read and write
git init --shared=all # same group can read/write, others can read

You can also set this after the fact, by setting the configuration variable core.sharedRepository. See git config --help for more information.

darcs add

git add <dir-or-file>

darcs record

Git supports interactive recording very similar to darcs.

git add -p

or

git add -i

The main difference is that Git does not automatically commit the changes. You have to do that manually using

git commit [-m "commit message"]

If you do not supply a commit message, it will open your default editor. If you want to abort the commit, use an empty commit message.

To see what will be committed, use

git diff --cached

Tip: If you want to see the diff when you edit the commit message, use

git commit -v

darcs record -a

git commit -a

This will add and commit all (not ignored) files. It will not add newly created files. (To do this call git add . before in the repo root directory.)

darcs pull

There is no direct mapping for the interactive darcs pull. Cherry-picking is not as streamlined as in Darcs.

darcs pull -a

Here is how you update (everything) from the source repo:

git pull

If all you want to do is to keep updated then this is fine. The above is actually a shortcut for

git pull origin

where origin is the name of your default remote branch. (You can name it as you like, but certain Git commands will use origin as the default if no argument is specified.)

XXX: will this pull into the current branch, or always into master? (Websites suggest always into master, so you likely need to follow git pull with git rebase <branch-name>)

Like in Darcs, you may get conflicts. To resolve conflicts, edit the conflicting file, git add it, and git commit it.

If you want to see whether you get conflicts before pulling git pull is actually ... XXX

darcs push

Selectively pushing patches is not available directly in Git. git push does the same as darcs push -a.

A comparable interactive workflow is to merge a selection of patches from a local branch into the local master branch and then git push that.

In general, even though a central repository is possible, Git promotes a pull model. That is, to work on a project you typically "fork" (git clone) the source repository, add your changes, publish your repository, and send a pull-request to the upstream maintainer. The reasoning behind that is that you don't have something akin to a list of committers, but rather the maintainer has a set of trusted peers. This model is very different than what seems to be common among darcs users, but it has its advantages.

Obviously, this requires that it's made easy to publish your version of the repository easily. This is where websites like ​GitHub come into play. GitHub is free for open source projects (it offers a paid service with private repos), and makes it particularly easy to share with Git. GitHub automates things like forking and sending pull requests. GitHub has a quota of 100 MB, but a forked repository will not count on your quota. This is particularly useful for large code bases like GHC. (The GitHub quota isn't always correct; so if it seems wrong check again the next day.)

darcs push is also used to exchange patches between local repositories. See "Local Branches" below for how to work with branches in Git.

Of course, you need to be able to publish your local changes to a remote repo (even if it's not the main repo). This is done using git push which is largely equivalent to darcs push -a

darcs tag

git tag <tagname>

This will fail if the tag already exists. If you want to move an existing tag use git tag -f <tagname>, but never move a tag in a public repo/branch. Use this only on local branches, and only if the tag exists nowhere else. git tag --help contains a discussion of this.

darcs whatsnew

git status

darcs diff

git diff

git diff <commit1>..<commit2> # show diff between two commits

darcs revert

Not sure if this gives you fine-grained reversion of individual hunks: