[petsc-dev] [mpich-discuss] MPICH migration to git

[Sean Farley]

On Wed, Jan 9, 2013 at 5:48 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>   Yes but given their absolutely horrible decision to stick with SVN all these years I cannot trust their decision to go with GIT. Sadly this is a very big argument for NOT switching PETSc to GIT. This email is only partly in jest, it has a serious component as well: is the "everyone's switching to git" just a case of the sheeple following the latest new thing without a proper technical evaluation or is it a carefully thought out decision?

Sigh. I will regret getting involved in this discussion, I'm sure.
First of all, switching from any centralized repository setup (cvs,
svn, perforce) to a decentralized setup is a win. Jed will tell you
that the git's branches are the only way to use that particular
workflow (which is not true). Between mercurial and git, there are the
following similarities and differences,

* branching
  - git has light-weight branches (this means that the branch metadata
is not written in the changeset)
  - mercurial calls these things bookmarks

The important thing to remember about using mercurial branches is that
they are just like svn (i.e. permanent). So, if you're looking for a
light-weight branches then simply use mercurial's bookmarks. You might
as well forget about the `branch` command if want to compare to git.

Unfortunately, Jed is right that bookmarks have some rough spots but
1) it's finally being dog-fooded and 2) development with branches /
bookmarks in mercurial will be much better after changeset filtering
is implemented (which looks like it was pushed to crew today,
actually). I haven't seen any problems using bookmarks in my everyday
workflow, especially with evolution.

* user interface
  - git has notoriously had a bad interface and even when I think some
command will do what I want, it somehow messes up
  - mercurial has a pretty clean interface for the most part (and more
importantly) makes typing shorter commands possible

* speed
  - tough to really say now that Bryan O'Sullivan's patches are in
mercurial and he's actively working on that front (for Facebook … who
still uses subversion)

* mutable history
  - git decides this based on whether there is anything "pointing"
  - mercurial decides what is rewritable by the phase (public, draft, secret)

This last bit of mutable history is what I've found to be an
indispensable workflow. I haven't seen any comparison of this
mercurial feature with modern git (to be fair, it's with a develop
version of mercurial).