Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

[Garrett Cooper]

On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremy <peterjeremy at acm.org> wrote:
> On 2011-Jan-21 20:01:32 +0100, "Simon L. B. Nielsen" <simon at nitro.dk> wrote:
>>Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful?
>
> Can cvsup-master still lose atomicity of commits?  I suspect it can,
> in which case syncing directly off the SVN master would seem a better
> approach.

I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I
wonder if it's time to look at another solution to this problem as
these annoying stability issues don't appear to be going away. What
about git?

Just some things I'm able to rattle off that come to mind with git..

Some arguments `for git'...

1. One tool to rule them all:
   - cvsup/csup can be replaced with git archive [1].
   - cvs git scales a bit better.
   - less support cost for p4 and lower likelihood of downtime in the
event of critical failure (perforce's proprietary DB is a pain to
recover I've recently discovered from other dealings).
   - svn <-> cvs exporter is no longer required as it's all one SCM.
   - As a side-effect, the bits present in CVS and SVN would now be
100% in sync, unlike cvs which can lead svn in terms of commits (at
least that was the case when I last talked to someone about version
numbering in pkg_install done by re@).
2. More evolved tool:
   - branches are cheap and can be local or remote.
   - distributed SCM seem to work well with large groups of developers.
   - works better with branching and merging from what I've seen.

Some arguments against git...
- The one caveat to cvsup/csup that's awesome is its componentization
capability, i.e. being able to selectively download components in src
/ ports; I'm not 100% sure but there doesn't appear to be a clear
analog in git. It might be achievable through gits remote.<group> in
git-config, git-remote, etc, but I would need to prototype whether or
not this is true.
- Higher learning curve.
- Some slightly annoying nits with stashing local changes when working
on separate branches (need to talk to git maintainers).
- <More items might be here>

    Some more git experienced folks could comment here, but it would
be nice to unify all of the systems under `one flag' for the sake of
simplicity and hopefully the sanity of the tool maintainers (Simon, et
all).
Thanks!
-Garrett