Lundkvist Per <per.lundkvist@xxxxxxxxxxxxx> writes: > But it seems like if we allow unsigned empty merge commits, i.e. those that > themselves do not introduce any any other change than what its parents > introduce, and require all other commits to be properly validated, then we can > safely validate the whole repository? Depends on what you are trying to protect against, I would think. Two tl;dr of it are * a merge that does "not introduce any other change than what its parents introduce" can still cause harm to the codebase. * a merge that introduces other changes may very well be necessary to merge two histories. Each commit signed by known/authorized people is simple. But what does it mean for them to sign an individual commit in the first place? "I wrote it" is too naive an answer ;-) A commit that is perfectly good in one context may cause the codebase to do a totally wrong thing in a different context, so your sign on the commit itself may assure others that you as the area expert vouches for the change in its original context, but will that signature be good enough to hold you responsible for the catastrophe it may cause by merging the history leading to the commit to a history that has forked from the original one long ago?
