Friedrich W. H. Kossebau wrote: >> For Git, the answer is: we can't. The whole accountability with Git >> rests not on the tool, but on the social network and the trust between >> the parties. In other words, you can't detect it later, but the >> structure of the project should detect it before it happens. >> >> The first suggestion I came up with was to ensure that, every push you >> make to the server contains only commits whose author and committer >> are you, yourself. That way, you can't impersonate others. >> >> The problem with that suggestion is that it completely prevents merges >> from other people's code. That is, I can't take your ingenious code, >> merge into my main tree and push to the server. > >Yes, this spoils all the fun with DVCS. But then I wonder: why would > there be a need for that. Why don't branches on the official server do > it for you? Read as: I fear a big problem with DVCS will be the > favouring of private developer circles, stealing a little of the Open > from Open Source.
Because it still requires you to get an account on the server and push it to the server before I'm allowed to use your changes. Of course, I could squash them into changes of my own before I submit, but then we're not gaining anything from the distributed nature of the system. If we require all commits to be on the same repository (not just the same server!) before they can be merged, we have successfully re-centralised everything. Think, for instance, of distributions that develop patches locally. Publishing their changes is part of the open source contract, but should we have to force them to upload their changes to our server (each developer) before we can make use of them? >> A fifth suggestion is then to have the server log every push and >> include the account name of whoever did the push. This could even be >> done in the repository, by way of tagging every push. With clever >> hooks, the server can prevent your pushing of tags that would make the >> log ambiguous. > >How does this help with the example you gave at the beginning? It helps knowing who introduced the change into the server. It wouldn't prevent completely that from happening, though. As I said, it has to rest upon the social structure. If the people who have push rights are trustworthy, then you trust them to push only stuff they agree with. That would include not pushing commits from fake authors. >> Then I have to ask: how paranoid are we? What's our objective here? To >> give credit where credit is due? Or to wash our hands of any guilt >> should something catastrophic happen in the future (e.g., copyrighted, >> patented code is found on KDE in 2015 and someone wants to assign >> blame)? > >Good questions :) I want to answer: our objective is give credit where credit is due. So the existing schemes already work. We don't have to introduce any kind of tagging. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
