On 2024-09-06, Leo Famulari wrote: > On Fri, Sep 06, 2024 at 10:44:54AM -0700, Vagrant Cascadian wrote: >> Is it just me, or is rebasing branches disconcerting, as it likely means >> the person signing the commit is not necessarily the original person >> pushing the commit? This is worst for the now deprecated core-updates >> branch with many rebased commits... are people still updating the >> signed-off-by tags or whatnot? > > In Guix, the "signed-off-by" tag gives credit to the reviewer of the > patch, but doesn't indicate anything about authority to push to > guix.git. That sounds more like a Reviewed-by tag. from doc/contributing.texi: When pushing a commit on behalf of somebody else, please add a @code{Signed-off-by} line at the end of the commit log message---e.g., with @command{git am --signoff}. This improves tracking of who did what. ... @cindex Reviewed-by, git trailer When you deem the proposed change adequate and ready for inclusion within Guix, the following well understood/codified @samp{Reviewed-by:@tie{}Your@tie{}Name@tie{}} @footnote{The @samp{Reviewed-by} Git trailer is used by other projects such as Linux, and is understood by third-party tools such as the @samp{b4 am} sub-command, which is able to retrieve the complete submission email thread from a public-inbox instance and add the Git trailers found in replies to the commit patches.} line should be used to sign off as a reviewer, meaning you have reviewed the change and that it looks good to you: > In all cases, a commit that is pushed to guix.git will be signed by an > authorized committer. The signature system ensures that. > > If we are concerned about long-running branches being rebased and > commits losing their "original" signatures, I think it's not really > something to worry about. That's because the signature *only* tells us > that that the commit was signed by someone who is authorized, and it > tells us *nothing* else. The code-signing authorization is extremely > limited in scope. It doesn't tell us that the code works, is freely > licensed, is not malicious, etc. So, it doesn't matter who signs a > commit, as long as it is signed by an authorized person. My understanding of what properly signed commits tell me, at least in the context of Guix, is that the person who has signed a given commit has made reasonable efforts to ensure the code works, is freely licensed, and is not malicious, etc. That they agree to do those sorts of things and have a history doing those things is why some people are trusted (e.g. authorized) to push commits. Mistakes happen, and that is fine, but having the signatures allows some way to review who did what when unfortunate things inevitably happen, to try and come to understanding of what to do better in the future. What concerns me, is with rebasing hundreds (thousands?) of commits (e.g. recent core-updates rebase & merge), many of which were originally reviewed by someone other than the person signing the commit, and re-signing them reduces the confidence that the signature indicates processes were appropriately followed... guix pull does protect against moving to unrelated histories, so probably the worst dangers of rebasing will at least trigger some warning! live well, vagrant