Comparison with Git, Mercurial or Darcs?

[Stephen J. Turnbull]

Daniel Carrera writes:

 > > * Rename is a first-class operation, tracked like any other change and
 > >  maintaining consistent history of the file. This is a significant
 > >  lessening of tedium and worry, allowing for how filesystem entries
 > >  change over the course of working on a project.
 > 
 > As I mentioned earlier, Darcs does this. I was surprised that other
 > VCS tools do not. I expected all modern VCS tools to correctly
 > represent my intentions.

For git, at least, it's a deliberate difference in philosophy.  git is
a *content* tracker, not a *change* tracker.  git considers that if
you do

    mv 1000-line-file-a 1000-line-file-b
    tail -999 1000-line-file-b > 1000-line-file-a 
    sed -i -e "2,1000d" 1000-line-file-b

you really haven't moved the contents.  OTOH, if you do

    for i in 1000 850 700 550 400 250 100; do
        head $i 1000-line-file-a | tail -100 >> file-b
        sleep 86400
        sed -i -e "$((i-99)),${i}d" 1000-line-file-a
    done

you have moved the contents, and it really should be considered a
rename.  git considers it more important to be able to track a named
function as it moves from file to file across refactorings (the
"pickaxe" functionality) than to be able to record your "intention to
move file".

Note that in all practical cases I can think of git *will* correctly
detect your renames (even if you forgot to say "git mv") and that with
appropriate options (considered "expensive" and therefore off by
default) it can display history of a file correctly (up to the
infinitesimal probability that you did something like example A
above).

I guess the lesson is that there is more than one way to do it, and
you need to be careful about these things if they matter to you.
Personally, I find the git way of doing things more useful for my
projects and my workflow, but I can easily see why large Java
refactorings would *demand* explicit rename support, and have no
trouble imagining that you would prefer it.

 > > * The interface is far smoother and more consistent: it uses readline
 > >  for command-line input, it handles Unicode properly,

I'm not sure what Ben meant by that, but for the interpretations I can
think of it's strictly speaking false (specifically, on Unix bzr is
not going to handle mixed encoding directories correctly until PEP 383
is implemented, ie, in Python 3).  The best you can say is that it's
better than the competition and will handle most practical cases well.

 > >  common options are sensible between commands, interfaces to
 > >  external tools are done well, etc.