Re: Tracability in git commits

[Richard Purdie <rpurdie@rpsys.net>]

On Wed, 2008-04-30 at 03:06 -0700, Jakub Narebski wrote:
> Richard Purdie <rpurdie@rpsys.net> writes:
> 
> > I've been wondering about whether its possible to provide some degree of
> > traceability of commits to a shared git repository. The potential
> > nightmare scenario is one developer making a commit pretending to be
> > someone else.
> [cut]
> 
> If you really need that, perhaps you would be better with using
> Monotone, with its elaborate security and trust-related features?
> 
> IIRC we recommended Monotone to IPSec folks here...

The project I'm thinking about is OpenEmbedded which used to use
bitkeeper and switched to monotone when bitkeeper went private only.

The issues with monotone are ones of poor performance, particularly with
the usage patterns we have, lack of good branching/merging capabilities,
lack of good web interfaces, high server load, some breakage issues and
a now general ill feeling amongst OE's developers.

Whilst monotone has improved tremendously from where it was, I'm not
sure certain features we need are going to appear in it within the
medium term which makes git look attractive.

When we switched to monotone we also lost our bitkeeper history which
I'd like to see us reunited with. I've been trying to make a sane
conversion of the bkcvs dump to git using git-cvsimport and the bkcvs
mode of cvsps but I'm having problems which I'll perhaps mention in
another email once I've had time to try and understand them properly.

Its by no means certain OE will switch but we want to setup a git trial
system and see exactly what we gain/lose. Evaluating the 'security'
consequences of a move is part of the equation. hg is another option
under consideration but not many of us have experience of it and we're
wary of choosing an SCM with a smallish userbase again amongst other
things.

Cheers,

Richard