Grzegorz Kossakowski <grek@xxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
