Hacker News Reader

Comment by mmcclure | Hacker News Reader

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.

View on HN

So, when submitting to your project it can happen that I'm afterwards blamed for things I didn't do? (Or praised)

I'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.

I 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).

If someone is concerned about getting blamed or praised for his work, he can sign his commits.

Ah 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.

That's the problem with all these guys obsessed with clean commit history.

What's wrong with having a clean commit history?

I think it's something people take too lightly.

Nothing. Just like there's nothing wrong with not having it clean.

> there's nothing wrong with not having it clean.

Untrue.

Depends on the project. If I ran the Linux kernel, I'd insist on clear commits too.

Oh 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.

I'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.

You need that level of traceability on each commit specially on the Linux kernel, all our little projects sure, destroy the history, is fine.

Well, as this submission demonstrates... you lose integrity and accountability

(which you never had in the first place, if you don't sign your commits)

I 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.

I 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.

You are correct, the Author will stay the same and the Committer will be the person who squashed.

You’re doing a rebase, which is not the same thing as purposely editing the commit author credentials.

Negative, 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...

Why 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.

Reply on news.ycombinator.com