Whygitisbetterthan.com, some advocacy from GitHub

[Stephen J. Turnbull]

Robert Collins writes:
 > On Mon, 2008-12-01 at 16:11 -0500, Elliot Murphy wrote:
 > > I while I use bzr and launchpad every single day, I really respect the
 > > work done at GitHub, and just saw this site:
 > > 
 > > http://whygitisbetterthanx.com/
 > > 
 > > Git is listed as better than bzr in 4 areas:
 > > 
 > > - cheap local branching
 > > - git is fast
 > > - the staging area
 > > 
 > > I don't understand why git is supposed to be better than bzr at cheap
 > > local branching, perhaps this is a case of not having a shared repo by
 > > default causes a surface evaluation to make git look better here.
 > 
 > Some people strongly prefer having branches not be real file system
 > objects; it does seem to make the workflow of 'switch between branches'
 > more evident when its the default (only!) way of working.

Hm?  In git making shared-repo separate-FSO branches is just as cheap
as in bzr.  Cheaper, in fact, because checkouts are perceptibly faster
(on a Mac iBook G4, as of bzr 1.8).  I always have a mainline checkout
as well as my local branch; it turns out that a "cd" is necessary and
sufficient for keeping the mainline unpolluted by rotten cherries --
for me.

 > We need a better UI answer here, but certainly a shared treeless
 > repo will perform pretty fast for making new branches.

Not fast enough for some workflows.  For my workflow branching and
committing should occur at the speed of thought.  Merging and diffing
don't have to be so fast.

 > It is now :). I think there are rational arguments about the UI
 > impact of the staging area - the way it is handled makes git need
 > unbreakme options - rather than a tool that empowers power-users,
 > its impacts the entire front end system behaviour.

Indeed it does, but in a favorable way IMO.  In particular, I make way
fewer "rotten cherry" commits with git than with any other VCS I use
(CVS, RCS, hg; I don't make enough commits with bzr or svn to have an
opinion from experience but I bet bzr is analogous to hg and svn to
CVS in this respect).  Casual users just need to learn to do "git
commit -a" to get bzr/hg-like behavior.  As a project manager, I
consider the bzr/hg behavior to be an attractive nuisance; it
deprecates coherent changesets.

 > bzr's shelve is great, but it would be nice to have more to offer there.

I'll have to try it, but I suspect it will be too slow.