Re: How to clone git repository with git-svn meta-data included?

["Shawn O. Pearce" <spearce@spearce.org>]

Grzegorz Kossakowski <grek@tuffmail.com> wrote:
> Peter Harris pisze:
> >> What if A was not fair and has rewritten a few commits coming from B so they contain malicious code?
> >> How we can detect something like that and how C be sure that what he merges is really work
> >> attributed by correct names?
> > 
> > If C doesn't trust A, C should not pull from A. C should pull only
> > from (trusted) B. Presumably B knows who (of A and B) did which work,
> > and B's repository can be trusted?
> > 
> > If neither of A or B can be trusted, then you have problems that a
> > computer cannot solve for you.
> 
> Yep, I was having in mind the case when both A and B are untrusted. I don't want my computer to
> check if something coming from A or B is safe or not I just want to know which bits are coming from
> A and which from B.
> 
> This is really important for us because of legal reasons.

ASF probably has issues similar to that of the Android project.

In Android we built Gerrit[1] to handle this validation of identity
for us, and to keep track of the contributor agreements each
individual and corporation has signed.  Changes aren't accepted
into Gerrit unless the user has an accepted CLA in the data store.

*1* http://review.source.android.com/

Gerrit 2 is actively under development and is being ported off of
Google App Engine, into a pure Java webapp.  I'm running it under
Jetty, but it should work just as well under Tomcat.  :-)

If the ASF becomes more committed to supporting Git, Gerrit may be
a good way to answer some of the questions you are having about
validating identity of changes.  Plus its a handy source code
review tool.
 
> > You could maybe use signed tags ("git help tag") - each contributor
> > could sign a certain tree state, [...]
> 
> The question is why Git doesn't sign all commits by default but only tags? Creating tags all the
> time is rather tedious process and seems to have no sense, right?

Yea, its tedious to unlock your GnuPG key every time you make a
commit.  Especially if you are just rebasing a series or something
to fix a minor mistake 5 commits back before uploading somewhere.
 
> Does it mean that with current Git design it's the best to not use advanced features of Git like
> tree merging but simply go with posting e-mails with patches instead if contributors cannot be trusted?

Most Git projects rely on patches sent to an email list, with
a single maintainer applying them to to his/her repository, and
publishing the result.  The maintainer is thus forced to keep track
of the CLAs (if the project uses such things) and just trust the
From address of the message.

CLAs in the kernel and in git itself are less enforced than say
what ASF or Android requires.

Some Git projects give write access to the master repository to
multiple trusted parties; SAMBA and X.org are good examples of this
sort of strategy.  But I think in these cases those who have write
access are also very long standing members of the development
community who have known each other in person for many years,
perhaps far longer than a DVCS concept has existed.  So trust
between those with direct write access is slightly less of an
issue for these projects.

So long story short, I think Gerrit may be worth the ASF's time,
if Git is a serious consideration for replacing SVN.  But while a
project is based in SVN I think the best you can do with Git is
publish an automatically updated git-svn mirror and permit only
use of "git svn dcommit" to upload back into the SVN repository.

-- 
Shawn.