On Fri, Jun 1, 2012 at 11:36 AM, Andreas K. Huettel
>> On 2 June 2012 03:12, Andreas K. Huettel <firstname.lastname@example.org> wrote:
>> Yes. Which basically means, you *cannot* have both
>> a) rebase only merges
>> b) every commit must be signed
>> as policies.
> I would say that this is a very strong argument in favour of allowing merge
One advantage of merge commits with signatures is that the history
really does reflect who signed what.
Proxy maintainer signs a bunch of ebuilds. I merge them in. The
commits show that the proxy maintainer signed a bunch of work done
against an old tree, and I signed a bunch of merge diffs that
basically synced them up to the new tree.
However, this is missing another issue. What is the value of
preserving all those original signatures in the first place? I'd
think that they'd mainly be used as some kind of web-of-trust. Well,
would such a web-of-trust include proxy maintainers in the first
If you want the tree to be traceable to Gentoo devs, then rewriting
the signatures is probably a good thing.
However, Kent did point out the rebase function doesn't actually apply
new signatures to the "new old" commits anyway, so you'd end up with
unsigned commits in the history.
git-rebase is just a shell script, that ultimately just calls
git-commit as far as I can see, which means that implementing
re-signing is just a matter of adding the appropriate parameters, or
use default configuration (assuming it doesn't already do this).