git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Tracability in git commits

From
RPRichard Purdie <rpurdie@rpsys.net>
Date
Apr 30, 2008, 10:32 UTC
Message-ID
<1209551520.5010.20.camel@dax.rpnet.com>
In-Reply-To
<m3lk2vodw4.fsf@localhost.localdomain>
On Wed, 2008-04-30 at 03:06 -0700, Jakub Narebski wrote:
Show 12 quoted lines
> 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
Previous: Jakub NarebskiNext: Martin Langhoff
Message 11 of 15 in “Tracability in git commits”
  1. Richard PurdieApr 29, 2008
  2. Johannes SchindelinApr 29, 2008
  3. Junio C HamanoApr 29, 2008
  4. Richard PurdieApr 29, 2008
  5. Shawn O. PearceApr 30, 2008
  6. Ping YinApr 30, 2008
  7. Miklos VajnaApr 30, 2008
  8. Shawn O. PearceMay 1, 2008
  9. Ping YinMay 1, 2008
  10. Jakub NarebskiApr 30, 2008
  11. Richard PurdieApr 30, 2008
  12. Martin LanghoffMay 1, 2008
  13. Martin LanghoffMay 1, 2008
  14. Junio C HamanoMay 1, 2008
  15. Martin LanghoffMay 1, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.