3 ms·

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

mmcclure 11y ago
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.
- jchung 11y ago
  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).
  - bluehawk 11y ago
    If someone is concerned about getting blamed or praised for his work, he can sign his commits.
    - deleted 11y ago
      [deleted]
  - mmcclure 11y ago
    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.
igorgue 11y ago
That's the problem with all these guys obsessed with clean commit history.
- ionforce 11y ago
  What's wrong with having a clean commit history? I think it's something people take too lightly.
  - seba_dos1 11y ago
    Nothing. 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 ago
      Depends on the project. If I ran the Linux kernel, I'd insist on clear commits too.
      - Pharaoh2 11y ago
        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.
        bronson 11y ago
        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.
      - 11y ago
sthomas1618 11y ago
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'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 ago
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).
- bluehawk 11y ago
  If someone is concerned about getting blamed or praised for his work, he can sign his commits.
  - deleted 11y ago
    [deleted]
- mmcclure 11y ago
  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.

igorgue 11y ago

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

ionforce 11y ago
What's wrong with having a clean commit history? I think it's something people take too lightly.
- seba_dos1 11y ago
  Nothing. 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 ago
    Depends on the project. If I ran the Linux kernel, I'd insist on clear commits too.
    - Pharaoh2 11y ago
      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.
      - bronson 11y ago
        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.
    - 11y ago

sthomas1618 11y ago

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.