Oswald Buddenhagen wrote: >On Thu, Jul 31, 2008 at 03:07:37PM +0200, Thomas Zander wrote: >> This will mean the content of both the master and the loggingOfMaster >> branches will be identical. The merge action creates a commit. A >> commit on the logging branch and one that the server automatically >> creates. > >that means that every branch will have a shadow branch, and every commit >(or commit group, as in push) will have a shadow commit. considering >that everyone will have the *entire* history of each module he is using >on his disk, i'm not really happy about that.
The extra cost is minimal. If each of the shadow commits were completely uncompressed, they'd be 100-200 bytes in size, more or less. And they are compressed, so that the end result is pretty small. Besides, you don't have to clone the shadow commits. >also, i think it is simly >overkill: a) the server could append to the log message something like >that: "Warning: author's email address does not match any registered >address of the submitting account (thiago)." It can't. The server can't change commits. It could only reject commits, but that goes back to the problems I listed in other emails: there are very legitimate uses for pushing other people's patches. But I agree it's overkill. >b) to further reduce >clutter, this warning could be appended only to the mail sent to >kde-commits. as an actual dispute over authenticity is an absolutely >marginal case, it can be very well referred to server logs. for >transparency and efficiency, the logs could be made available through a >web interface. Indeed. That's what I argued with Thomas as well: for our (KDE) purposes, the kde-commits mailing list is the accountability we need. It's archived in several independent websites, so tampering with is very difficult. >> For this usecase I want to introduce a completely separate >> accountability concept that is similar, but different, from the git >> concept of signing off. > >i wonder why you introduce two concepts instead of suggesting this one >for both cases? We just listed both possibilities. >an alteration to the concept: instead of removing the received >signature, you would sign it, too. this would actually *be* the >kernel-style signed-of-by concept, only that it would be >cryptographically signed. Indeed. Our idea was a "Signed-off by" that cryptographically signs. Unlike the kernel-style signing off, this cannot be used with rebases and git-am. It requires a full-fledged merge. When we were discussing, we started off on signatures like git tag -s. But we can't sign a commit's SHA-1 before we have that SHA-1. So, instead of signing the digest, we decided we could sign the information that would have been digested: the headers and message of the commit. The other solution (which has appeared here) is to sign your diff. The idea has its merits, but it's actually harder to implement given Git's object model. Besides, as soon as there's a single line of difference (a fuzz of one line because someone added a blank line somewhere above the lines that the patch touches), the signature wouldn't work. -- 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
