I’m curious in what aspects they have not been! This reads more like “updating the web interface to support an occasionally used git feature” rather than “fixing an incorrect implementation of git in use at GitHub”.
(Aside: a lot of the people I see using signed commits right now are probably the type who’d eschew a web interface entirely; here’s hope this feature will make it more common!)
It’s pretty clear that proper in benoliver’s comment refers to feature complete, not “correctness”.Though a duck without a bill is probably not correct, not to be ableist.
I’m super excited to see this! Sadly, this doesn’t extend to the case where people merge pull requests from the web interface with the big green “Merge” button - this still generates unsigned commits, and with an Author: line that corresponds to the email address the github user signed up with initially (no org-specific email, even if you set it in your notification preferences).
I really hope that github will eventually allow orgs to disable that merge button on a repo-by-repo basis, so that repos that take advantage of the commit-signing features get signed commits more consistently.
I really hope that github will eventually allow orgs to disable that merge button on a repo-by-repo basis
I wonder if it wouldn’t be good enough (or better!) to pop up a suggestion on the PR page that you might want to perform the merge on the command line instead if there are signed commits detected in the branch (or in recent history in the repo, or by your user in the repo history ever, etc.).
A way to safely integrate with code under the user’s control would be great. At a minimum it could offer a link to open that PR in the GitHub desktop app (together with a firm admonition to review the PR there, and not in the possibly-compromised web UI). Though that desktop app is self-updating so I’m not sure how much that actually buys us.
When a commit is signed, what is actually signed? Is it just the diff, or the diff and metadata? If you were to rebase a series of commits would the signatures become invalid even if each individual commit diff didn’t change? I assume so, but I wanted to confirm.
Good to see GitHub moving towards properly implementing git…
I’m curious in what aspects they have not been! This reads more like “updating the web interface to support an occasionally used git feature” rather than “fixing an incorrect implementation of git in use at GitHub”.
(Aside: a lot of the people I see using signed commits right now are probably the type who’d eschew a web interface entirely; here’s hope this feature will make it more common!)
For me its lack of notes support and the inability to customize a pull request’s merge message template at a repo owner level.
I suppose these both also don’t feel like “an incorrect implementation of git” either.
It’s pretty clear that proper in benoliver’s comment refers to feature complete, not “correctness”.Though a duck without a bill is probably not correct, not to be ableist.
I guess the whole crux of my reply was that it wasn’t pretty clear, but I take your point.
I’m super excited to see this! Sadly, this doesn’t extend to the case where people merge pull requests from the web interface with the big green “Merge” button - this still generates unsigned commits, and with an
Author:line that corresponds to the email address the github user signed up with initially (no org-specific email, even if you set it in your notification preferences).I really hope that github will eventually allow orgs to disable that merge button on a repo-by-repo basis, so that repos that take advantage of the commit-signing features get signed commits more consistently.
I’m pretty serious about my crypto but I do think signed release tags are probably enough, signing every single commit seems like overkill.
I wonder if it wouldn’t be good enough (or better!) to pop up a suggestion on the PR page that you might want to perform the merge on the command line instead if there are signed commits detected in the branch (or in recent history in the repo, or by your user in the repo history ever, etc.).
A way to safely integrate with code under the user’s control would be great. At a minimum it could offer a link to open that PR in the GitHub desktop app (together with a firm admonition to review the PR there, and not in the possibly-compromised web UI). Though that desktop app is self-updating so I’m not sure how much that actually buys us.
When a commit is signed, what is actually signed? Is it just the diff, or the diff and metadata? If you were to rebase a series of commits would the signatures become invalid even if each individual commit diff didn’t change? I assume so, but I wanted to confirm.