RosettaStone

Translations

Initialising and cloning

conceptdarcsgithgbzr
new repositoryinitinitinitinit
copy repositoryget (aka clone)cloneclonecheckout
branchsee checkoutbranchbranchbranch
switch branchna [1]checkoutupdate?

Adding, moving, removing files

conceptdarcsgithgbzr
track fileaddaddadd?
copy filenajust copy it, git might noticecopyna
move/rename filemove (aka mv)mvrename (aka mv)mv

Inspecting the working directory

conceptdarcsgithgbzr
working dir statuswhatsnew -sstatusstatusstatus
high-level local diffwhatsnewnanana
diff localdiff [1]diffdiffdiff
  • [1] we tend to use the high-level local diff (darcs whatsnew) instead. This displays the patches themselves (eg 'mv foo bar') and not just their effects (eg 'rm foo' followed by "add bar")

Committing

conceptdarcsgithgbzr
commit locallyrecordcommitcommitcommit --local
commit to reposee push/sendsee pushsee pushcommit
amend commitamend-recordcommit --amend??
tag changes/revisionstagtagtagtag

See below for comments on record vs commit.

Inspecting the repository history

conceptdarcsgithgbzr
logchanges (aka log)logloglog
manifestshow filesls-filesmanifestls
summarise outgoing changespush --dry-run [1]?outgoingmissing --mine-only
summarise incoming changespull --dry-runlog ..origin/masterincomingmissing --theirs-only
diff repos or versionsdiffdiffincoming /outgoing/diff -rdiff
blame/annotateannotateblame?annotate?
  • [1] if "pushing" to an HTTP repository, this will emit a warning that pushing over HTTP does not work, but the dry-run will still work

Undoing

conceptdarcsgithgbzr
revert a filerevert foocheckout foorevert foo
revert full working copyrevertreset --hardrevert -arevert
undo commit (leaving working copy untouched)unrecordreset --softrollback?
amend commitamend-recordcommit --amend??
destroy last patch/ changesetobliteratedelete the commitstrip [1]uncommit [2]
destroy any patch/ changesetobliteraterebase -i, delete the commitstrip [1]?
create anti-changesetrollbackrevertbackout

Collaborating with others

conceptdarcsgithgbzr
update from reposee pullremote updatepull -uupdate
pullpullpullpullupdate
pushpushpushpushpush
send by mailsendsend-emailemail [1]
merge-directive

--mail-to

  • [1] requires extension (patchbomb for email)

Advanced usage

conceptdarcsgithgbzr
port commit to Xna [2]_rebase/cherry-picktransplant?

* [2] usually not needed because of patch reordering, but see http://bugs.darcs.net/issue938 and http://lists.osuosl.org/pipermail/darcs-users/2010-August/024924.html if you really need darcs rebase now.

Discrepencies between DVCS

Git has the notion of an index (which affects the meanings of some of the commands), Darcs just has its simple branch-is-repo-is-workspace model.

Hg's rollback only works on one level and is not reversible. On the other hand, it seems to have an interesting, very general, idea of undoing transactions (general in that there are a lot of commands which are "transactional"). It should be studied a bit more carefully.

Superficial differences:

  • git revert is like darcs rollback
  • git reset is like darcs revert

See also DifferencesFromOtherDVCS

Recommendations for unification

Note that there are no current plans to rename commands. The following is some idle speculation on how darcs (and other revision control systems) can make it easier for users to go from one system to another. In particular, we want to be careful to avoid forcing things to have the same name if they actually have subtly different meanings.

Quoting Stephen Turnbull in http://lists.osuosl.org/pipermail/darcs-users/2009-July/020438.html

In general, I think that application of database terminology would be
a good idea, with the exception of "commit" because of the historical
context of CVS, and the very strong intuition that recording locally
doesn't commit you to anything (cf. the rebase controversy, where
everybody agrees that local rebasing is a mere peccadillo or even
beneficial, while rebasing a branch that has been published is equated
to smoking in an elevator filled with pregnant women).

General principles

There will be no swapping of command names in any system. That would just cause too much confusion. If any change were to happen, it would likely have to involve converging to a new set of consensus commands. This requires cooperation from all revision control systems.

Darcs

  • rename whatsnew -s to status (see http://bugs.darcs.net/issue182)

  • rename get to clone

  • rename changes to log

  • rename rollback to new "backout"

    • Eric originally suggested "repeal", but everybody hated it, including Eric
    • "reverse" has also been suggested (although it sounds a lot like revert, which could be bad)
    • "invert" is another possibility (but maybe that has the same problem as "reverse")
    • "backout" has the nice property of already being used in the same way by Hg

darcs record stays

Note: one command we are making a point to keep is "darcs record" (as opposed to darcs commit). We think it's important to preserve the distinction between saving a change locally and publishing that change somewhere.

Also, here is what you get when you type in "darcs commit":

This command does not do anything.
If you want to save changes locally, use the `darcs record' command.
If you want to save a recorded patch to another repository, use the
`darcs push' or `darcs send' commands instead.

Others

We may not have much say in what others name things, but these may help build a consensus command set

  • git:rename revert to new "backout" (or whatever we collectively decide is a good name)
  • everybody: rename commit to "record" ;-)
  • bzr: rename uncommit to obliterate (potential source of confusion?)