6 ms·
TBH we "exploit" this when accepting PRs for an open source project I work on. It's not really feasible for us to expect / force each PR author to have a clean
by mmcclure 11y ago
TBH we "exploit" this when accepting PRs for an open source project I work on. It's not really feasible for us to expect / force each PR author to have a clean commit history, so we basically do some squashing, then commit the "single" change as the original author before merging.
- johannes1234321 11y agoSo, when submitting to your project it can happen that I'm afterwards blamed for things I didn't do? (Or praised)
- mmcclure 11y agoI'm not sure I follow? All of your work is intact and committed as you, it's just done as a single (squashed) commit instead of N commits. The only difficulty that potentially arises (that we've encountered so far) is a lack of granularity for commit messages, which is why we try to keep PRs very small and focused.
- jchung 11y agoI think what johannes1234321 is concerned about is that while you say the work is intact, he can't actually vouch for that because he didn't do it. You did. Which means that he could potentially be blamed (or praised) for something he didn't do in the event that you don't keep his work intact (intentionally or otherwise).
- bluehawk 11y agoIf someone is concerned about getting blamed or praised for his work, he can sign his commits.
- deleted 11y ago[deleted]
- mmcclure 11y agoAh ok, thanks for the clarification. Yes, that is technically a possibility, but to be fair, a big takeaway from this whole thing is that signed commits are the only way to really have guarantees of authorship. If you're knowledgable enough to do that, you probably have a reasonably clean commit history, which we generally don't squash before merging.
- igorgue 11y agoThat's the problem with all these guys obsessed with clean commit history.
- ionforce 11y agoWhat's wrong with having a clean commit history? I think it's something people take too lightly.
- seba_dos1 11y agoNothing. Just like there's nothing wrong with not having it clean.
- ionforce 11y ago> there's nothing wrong with not having it clean. Untrue.
- bronson 11y agoDepends on the project. If I ran the Linux kernel, I'd insist on clear commits too.
- Pharaoh2 11y agoOh no no no. If you are handling something as important as the Linux kernel, you will absolutely want traceability over anything as trivial as clean history. You will impose signed commits and signed merges only... none of these FF stuff. If you want clean history on top of that, you will enforce that on original pull request not after the fact.
- bronson 11y agoI'm responding to, "there's nothing wrong with not having it clean." Yes, there often is. And I do enforce it on the original pull request.
- 11y ago
- sthomas1618 11y agoI don't think that could happen: 1. The content of the PR will stay the same. In this case, the only thing changing is the number of commits. Unless you expect someone to blame (or praise you) for the number of commits? 2. Git will track the Committer and Author separately.
- swang 11y agoI don't think you need to do this? I may be wrong but I thought if you squash the author's commits git will still give the author credit for the commit.
- sthomas1618 11y agoYou are correct, the Author will stay the same and the Committer will be the person who squashed.
- hk__2 11y agoYou’re doing a rebase, which is not the same thing as purposely editing the commit author credentials.
- mmcclure 11y agoNegative, we're actually editing the commit author credentials when we create the final commit message, which adds a Changelog message and closes the original PR. https://github.com/videojs/video.js/blob/master/contrib.json#L358 https://github.com/videojs/video.js/blob/master/contrib.json...
- hk__2 11y agoWhy not just doing a rebase? I work on a big open-source project on Github and we do rewrite/squash commits to have a clean history, but it only involves a rebase, not editing the author credentials.