On 31 jul 2008, at 15:07, Thomas Zander wrote:

> When Diana makes several translations she does this on a git  
> checkout. She
> then commits her changes and emails or pushes her changes to Carlos.
> Making a commit in Git is something that is done in several steps  
> and the last
> step is to create a commit message.  Diana will use a way of  
> committing[1]
> that takes the commit message, the tree (including her changes) and  
> her email
> address and it will gpg-sign that information.
> This signature will be added to the logmessage, probably as a one- 
> liner of
> ascii data.

If you want to sign the tree that includes Diana's changes, you have  
to make
sure that you also know on which tree the changes were applied. This
information might not be available in every patch, and if you apply  
the patch
on a different source tree, you will get another final tree, and the  
sha1 will
not match.

Why not use a hash of Diana's patch instead of the final tree? That  
way the
patch can be applied on every tree and still retain a valid sha1.

Don't you think all this signing off will make it harder for first- 
timers to
send in a patch? Or is this purely optional, for people that don't  
have commit
access but don't want to put the responsibility on the maintainer? Why  
not
give them commit access?

> The effect of signing this is that we can now send around that patch  
> and merge
> it into any tree without loosing the information about who really  
> initially
> created that patch.
>
> Ok, back to our Carlos usecase;  Diana created the patch, she signed  
> it and
> then pushes it to Carlos.  Carlos checks the signature using some  
> custom
> script to make sure the commit really is from Diana and he merges it  
> into his
> tree.
> At a later point he pushes all the changes he has, including the one  
> from
> Diana, to the kde-server.
> The commit is registered by the kde-server as being made by Carlos,  
> but Carlos
> can point to the signature to indicate that, really, Diana was the  
> one that
> made this commit.

Have you thought about using person-specific branches? For example,  
let's take
the previous use case with Diana. Diana does not have push access to a  
specifc
project, but she does have push access to her own namespace (branches/ 
diana/*
perhaps). She pushes her change to her own branch, and asks Carlos to  
pull it.
Carlos merges the branch, and pushes it. The server-side hook can see  
that the
patch originated from diana's namespace, and give accountability to her.

You might even use something like git patch-id to make this possbile  
for random
patches, so that accountability remains after a rebase.

- Pieter
_______________________________________________
Kde-scm-interest mailing list
Kde-scm-interest@kde.org
https://mail.kde.org/mailman/listinfo/kde-scm-interest