Drop Co-Authored-By from squashed commit?

[Mark-Simulacrum]

It's not uncommon that I'll squash commits for a contributor before approving. In most cases, this is a pure squash; I'm not touching the code myself (beyond review done). However, it seems like bors today inserts Co-Authored-By unconditionally into the resulting commit which is a bit misleading. Can we stop doing that unless there's a commit authored by me? Or maybe make it an opt-in/out flag to squash?

[Kobzol]

Bors doesn't add Co-Authored-By for the person doing the squash. It does so for all authors of the squashed commits (other than the author of the first commit, usually the PR author, who is attributed as the "main" commit author).

Do you perhaps have a link? E.g. here teor got added as a co author because you accepted their typo fix through the GH UI (rust-lang/rust@c661a83), so he was an author of an intermediate squashed commit.

[Mark-Simulacrum]

Hm, I think rust-lang/rust@b27f703 is what prompted the one I was confused about.

I guess my thinking is that I disagree on co-authored for a typo fix, which is the common case for GitHub suggestions. Maybe there's nothing that can be done without complaining to GitHub about that behavior though.

[Mark-Simulacrum]

I think we can either close this as won't fix / working as intended, with the suggestion being to manually write the message, or have a flag of some kind. Maybe msg=description would work (pulling from the PR description, like bors already does for merge commits)?

[Kobzol]

I don't think that we can detect whether the Co-Authored-By trailer was added by a typo fix, rebase, or manually.

I didn't understand the part about the flag and msg.

[Mark-Simulacrum]

I don't think that we can detect whether the Co-Authored-By trailer was added by a typo fix, rebase, or manually.

Hm, I think it's possible that we could if we looked for the GitHub-owned signature on the commit (which I think can ~only be produced via the suggestion UI).

I didn't understand the part about the flag and msg.

IIUC, if I pass msg="some message here", C-A-B is not added, right?

If so, to avoid hitting #773 and more generally to avoid long-form messages getting written out repeatedly, we could allow pulling the full commit body out of the PR itself, just like how bors generates "Auto merge of" commits from PR descriptions/titles. Opt-in to that could be via bors squash msg=description.

[Kobzol]

Hm, I think it's possible that we could if we looked for the GitHub-owned signature on the commit (which I think can ~only be produced via the suggestion UI).

Interesting. But I would still say that there are sometimes changes suggested through the GitHub UI that are not just typo fixes, but actual non-trivial changes for which I think we should keep attribution :)

IIUC, if I pass msg="some message here", C-A-B is not added, right?

Ah, that's not fully accurate. If you use msg, then bors won't generate C-A-B extracted from the commit messages of the individual commits, but it will still generate C-A-B based on the actual authorship of those commits. But in the case of GH UI suggestions, the commit author will be the PR author everytime, I think.

Opt-in to that could be via bors squash msg=description.

Hmm, the PR description will be automatically included in the merge commit, by bors. So the merge commit and its parent (from the PR side) would then have the same commit message, not sure if that is super useful. The auto-generated commit message at least keeps the original commit messages.

[Mark-Simulacrum]

So the merge commit and its parent (from the PR side) would then have the same commit message, not sure if that is super useful. The auto-generated commit message at least keeps the original commit messages.

The cases where I want to squash almost always have very useless original commit messages (or at least undesirable in my eyes); the reason I'm squashing is to get rid of them. So in my eyes I basically 100% of the time want nothing in the PR except the description (or similar content). If there's a meaningful commit history, I either wouldn't blanket squash or wouldn't squash at all.

[Kobzol]

I think I used to only have one message, but then created the commit message stream because someone asked for it =D So essentially, this issue turned into "I always want to use a specific message when squashing", right? And to make that easier, you'd like to have a shortcut like @bors squash msg=description that uses the PR description as the commit message?

[Mark-Simulacrum]

Yeah, I think that's basically right.

[Kobzol]

Ok, implemented that in #780.