On Mon, Nov 7, 2022 at 2:27 PM Jean-Luc Deprez <[email protected]> wrote: > > That's not correct AFAIK. Usually, the PR *opener* (not merger) is > > listed as the git author and Github is listed as the committer. This > > is a gotcha that bit us before when a PR had to be reworked and > > recommitted from another person, and then was finally squashed. > > Any chance that that behaviour depends on a) if there's one or multiple > commits, b) one or multiple authors of those commits?
As of at least a few months ago, it did not matter (but it might have in the past). > Following feature update seems to indicate that what I'm saying is not > complete nonsense. > https://github.blog/changelog/2022-09-15-git-commit-author-shown-when-squash-merging-a-pull-request/ It's related but maybe not as you think :) In any case, it is not clearly specified and information can be lost or changed in the process. Also, the behavior might have changed over time. In any case, just take the evidence from the pekko commit history. Consider all of the original Akka commits squashed with most PR openers not having commit rights. All of those have the original authors still listed and almost all committers are Github. > It sure seems like there an element of surprise to the matter > https://github.com/isaacs/github/issues/1368 This is actually also related to the above blog post. Since the final author relies on the PR opener and not on the commits at all when squashing, it is only consistent that Github may rewrite the author to use an email address it knows from the PR opener instead of the one creating the commit. It seems at that point (4 years ago) the committer might have been the merger but that's usually not the case right now. The added feature now at least shows what email will be used for the author and allows to choose in case the merger is also the PR opener (but unrelated to any commits the PR contains). > Anyhow, I think in general commit spoofing is not a well lit complication > of using Git, which did not exist with e.g. SVN. > https://mikegerwitz.com/2012/05/a-git-horror-story-repository-integrity-with-signed-commits Not sure what the point is? That git requires signatures for authentication (like many decentralized protocols) while svn was based on client-server-based authentication? > And while these guys haven't made many friends in OSS, I think they did > highlight very important risks. > https://www.phoronix.com/news/Hypocrite-Commit-Open-Letter This was not related to git at all, is it? It is more about some kind of social engineering to get changes accepted (which are hard to counter for projects on the scale of Linux). > But I will admit, the first doesn't really matter much if you systemically > squash. Rebasing is another story though. - squash rewrites commits giving authorship to the PR without regards to the authors in the commits themselves (possibly completely changing the original commits) - rebase keeps original commits as much as possible (but might change them as needed for rebasing) Not sure whether I can say with confidence if one or the other is better... --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
