> Adding `Co-authored-by`, usually works automatically in the Github UI for squashing but we have also seen instances where the UI was not working completely correctly, so some care is needed. The "merger" will only be included in the Git history as the author of a merge commit (in case merging was used). In case of squash and rebase, the merger will not be recorded in the history.
Indeed this is correct, github UI now automatically adds a Co-authored-by in the commit. I personally did not experience cases where it was not added, maybe Github improved it and/or I didn't hit such cases. On Mon, 7 Nov 2022, 12:56 Johannes Rudolph, <[email protected]> wrote: > On Mon, Nov 7, 2022 at 12:26 PM Jean-Luc Deprez > <[email protected]> wrote: > > 2. The GH Actor (so merger) is listed a author, which is fair, as the > > one deciding to make one commit. > > 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. > > Adding `Co-authored-by`, usually works automatically in the Github UI > for squashing but we have also seen instances where the UI was not > working completely correctly, so some care is needed. The "merger" > will only be included in the Git history as the author of a merge > commit (in case merging was used). In case of squash and rebase, the > merger will not be recorded in the history. > > > The GH signature testifies to the identity of the author, who was > authenticated in GH (yes that make GH a central authority on this front) > > Unfortunately not, it only testifies that Github created the commit. > In the best case (relying on Github's rules that may or may not change > in the future), we could say it testifies who the creator of the PR > was which still does not say anything about the contents of the commit > (or even through which PR it was merged). Most of this information can > be accessed through the GH UI but it's not recorded in the commit. > It's a common problem when doing code archeology to trace back how and > where things have originated... > > I still agree that all three modes can be useful and squash is a good > default because many changes are simple in structure and squash > simplifies the overhead required to apply simple changes. > > > That being said, it's very possible that this is an enterprise mindset > which doesn't fit an open source project. > > From my experience, OS is often more strict and principled about these > things than enterprises which often take whatever works as long as > there's some progress ;) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
