Re: [tlug] Open-source repository question

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:

 >     Darcs: Not as popular, and users of older distros may have to do a
 >     source build if you're using Darcs 2.0 and their packaging system
 >     has only 1.x. Not terribly fast.

Not to mention that ghc itself is questionably usable on some
platforms.  Sure, you can always revert to a previous version of the
package, but the way that about 1 out of 3 releases of ghc segfault
while bootstrapping the compiler (on Mac, for ghc 6.10.3 it's now 6 in
a row and currently broken, and I've had 2 broken releases in a row on
Gentoo somewhere around ghc 6.5) makes me wonder about the quality of
its code generator.

 >     Has some UI issues (such as the default action for a merge of
 >     conflicting file additions being to delete the
 >     file--ouch!). Has a so-called "theory of patches" which some
 >     claim gives it a sound foundation that other DVCSs don't have,
 >     but which actually is probably not such a thing.

It's not.  The reason why it's not is very simple to explain: a real
theory of patches needs a mapping from program syntax to global
program semantics in order to determine when two patches are "in
conflict".  Darcs doesn't have that *at all*, only a bunch of local
textual heuristics which are *known* to be wrong in some cases.

 >     I can't compare the merging tools with Git.

Darcs's UI for merging branches is pretty ugly (no indication of the
source of each version in the usual 3-way markup).  Its facility for
editing patches (at commit time) is what I think could be very useful
to somebody with several snapshots (as opposed to commit histories)
that they want to merge.

 > In Starling's programming style, we fairly frequently have two
 > developers working in separate checkouts on the same piece of code,
 > at the same time. [...] When the developer changin the API is
 > finished, he commits that change, and then the other developer does
 > an svn update, merges that change directly into his working copy,
 > finishes the feature, and commits. You'll note that during this
 > process there never exists a committed version of the code that
 > does not build and work properly.
 > 
 > The problem here is that git appears to have no way to let you merge
 > new commits into your working copy.

Personally, I think that makes very little sense in the git model.
It's like saying "you should never save a file that won't build to
disk, you should keep it in an editor buffer."  git is designed around
the idea that you can merge code into the working copy, or you can
merge branches in a commit, but you shouldn't do both in the same
operation.

 > Instead, you have to commit your changes, resulting in a commit of
 > a broken system with half of the new feature, pull the other
 > changes, do the merge and finish the feature, and commit again. I
 > suppose you can then go back and merge those two separate commits
 > into one commit that is a patch to move from the new API without
 > the feature to the new API with, I suppose, but that seems less
 > convenient to me.

I disagree.  You can easily get rid of the intermediate commit with

nukeit () {
    MIDDLE=`git-rev-parse HEAD^`
    LASTGOOD=`git-rev-parse HEAD~2`
    git filter-branch --parent-filter "sed -f s/$MIDDLE/$LASTGOOD/" \
                      HEAD~2..HEAD
}

(note that this requires merging from the other guy's branch to yours,
but that could be improved).

The advantage to having the temporary commit is that you can easily
revert the merge without reverting your previous changes if you get
one of those horrible merges.  OTOH, this (if you agree about
reverting) is exactly right because it does NOT have information about
merge parentage in any commit or the index until the merge actually
takes place.

 > The plural of anecdote is not "data," but we had one developer working
 > with Windows in our ICFP contest group, and he had no problem with git.
 > He's since worked on other things within git repos as well.

Well, I've worked on two CVS-to-DVCS transition teams now, and in both
cases the Windows people were unanimously in favor of the Python-based
DVCSes.  Small sample, but real data.

Of course, none of them actually had ever *tried* git. :-)  But that
doesn't stop them from disliking it!

I've also heard that the problems with git on Windows don't show up
until you're looking at scores of files with total volume counted in
scores of megabytes.  Then you start to run into the problem that
optimizing lots of system calls in Windows is very different from
optimizing lots of system calls in *nix.  Obviously, both Python and
Emacs qualify for concern on those measures.