On Fri, Jun 1, 2012 at 11:36 AM, Andreas K. Huettel <dilfri...@gentoo.org> wrote: >> On 2 June 2012 03:12, Andreas K. Huettel <dilfri...@gentoo.org> wrote: >> Yes. Which basically means, you *cannot* have both >> >> a) rebase only merges >> and >> b) every commit must be signed >> >> as policies. >> > > I would say that this is a very strong argument in favour of allowing merge > commits.
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 place? 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). Rich
