Hacker News Reader

Comment by johannes1234321 | Hacker News Reader

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.

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.

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)

Reply on news.ycombinator.com