DVCS - git
13 views
Skip to first unread message
Wheeler, Kyle Bruce
Sep 12, 2012, 4:40:32 PM9/12/12
to Qthread List
Hey all,
I mentioned before that I was considering moving to a DVCS, as a result of some of our collaboration needs. Having reviewed a lot of different arguments about the two main contenders, mercurial and git, I've decided to move to Git on a trial basis.
There are a couple reasons for this, and not all of them terribly technical. The general comparison between Git and Mercurial is that Mercurial is a little easier to learn, while Git is more flexible. Further, Mercurial makes use of extensions in order to obtain parity with Git's feature set, which sounds like a headache. But I think the biggest technical reason is that Mercurial takes the approach that history is sacred, whereas Git allows us to modify history (e.g. for clarity, or to remove commits that should have never become public in the first place). This is especially important when dealing with things like intellectual property and NDA'd code: we're all human, and accidents happen, but Git allows us to clean up, whereas Mercurial doesn't (yes, there is a history editing extension, but it's not quite as good: consider propagating edited history down to clone'd repos whose users don't have the history editing extension installed).
There are a few features in git that caught my eye as being nifty, too, such as being able to commit *partial* changes from a file. For example, after I've added all kinds of debugging info to a file and finally found the five-line fix, I can selectively commit the five-line fix without removing all that debug code from my local copy first.
The non-technical reasons are also important: we seem to have several developers that are already proficient with Git. Further, my office-mate is the Trilinos project's git-guru, so he can help me muddle through the transition period.
Now, I'm still working through what will be necessary to transition over to git (we will be sticking with Google Code, since the access and accounts and such are already all set up), but now that 1.8 is out, I figure this is a good time. From what I can tell, the SVN repo will stick around, it just won't get updated. That should help make this transition easy.
Unless there are arguments, I'll try to get this done *soon*.
--
Kyle B. Wheeler
Dept. 1423: Scalable System Software
Sandia National Laboratories
505-844-0394
I mentioned before that I was considering moving to a DVCS, as a result of some of our collaboration needs. Having reviewed a lot of different arguments about the two main contenders, mercurial and git, I've decided to move to Git on a trial basis.
There are a couple reasons for this, and not all of them terribly technical. The general comparison between Git and Mercurial is that Mercurial is a little easier to learn, while Git is more flexible. Further, Mercurial makes use of extensions in order to obtain parity with Git's feature set, which sounds like a headache. But I think the biggest technical reason is that Mercurial takes the approach that history is sacred, whereas Git allows us to modify history (e.g. for clarity, or to remove commits that should have never become public in the first place). This is especially important when dealing with things like intellectual property and NDA'd code: we're all human, and accidents happen, but Git allows us to clean up, whereas Mercurial doesn't (yes, there is a history editing extension, but it's not quite as good: consider propagating edited history down to clone'd repos whose users don't have the history editing extension installed).
There are a few features in git that caught my eye as being nifty, too, such as being able to commit *partial* changes from a file. For example, after I've added all kinds of debugging info to a file and finally found the five-line fix, I can selectively commit the five-line fix without removing all that debug code from my local copy first.
The non-technical reasons are also important: we seem to have several developers that are already proficient with Git. Further, my office-mate is the Trilinos project's git-guru, so he can help me muddle through the transition period.
Now, I'm still working through what will be necessary to transition over to git (we will be sticking with Google Code, since the access and accounts and such are already all set up), but now that 1.8 is out, I figure this is a good time. From what I can tell, the SVN repo will stick around, it just won't get updated. That should help make this transition easy.
Unless there are arguments, I'll try to get this done *soon*.
--
Kyle B. Wheeler
Dept. 1423: Scalable System Software
Sandia National Laboratories
505-844-0394
Reply all
Reply to author
Forward
0 new messages