3 ms·

> Managers, tech leads, or users of your OSS project don't care about the "fix typo" comments. They are interested in a meaningful history that tells a bigger s

> Managers, tech leads, or users of your OSS project don't care about the "fix typo" comments. They are interested in a meaningful history that tells a bigger story. Why would they be looking at the version control system for this? That is not what it's there for.

azernik 5y ago
That is absolutely what it's there for! git blame and git log are extremely commonly used, git bisect is only convenient in a commit history where breakage is uncommon, &c
- user-the-name 5y ago
  None of those require a "meaningful history that tells a bigger story".
pdimitar 5y ago
GitHub in particular is widely used by managers -- not the higher-level managers of course, but a lot of engineering managers have mastered the usage of GitHub issues, Markdown task lists inside PR descriptions, and reviewing results of CI/CD pipelines. And many tech leads simply don't have the time to review every single WIP commit. They want meaningful message/description of the big squashed PR commit. If you just post a merged list of all commit messages with 10x "fix stuff" inside you'll be in big trouble the next time around and your work will be inspected very closely. The practices I am describing to you are reality in many tech companies. Writing code there is not about you at all. And almost nobody will read your code and PR descriptions unless they really have to. Hence it's a professional courtesy to make those as small and meaningful as possible.
- user-the-name 5y ago
  > And many tech leads simply don't have the time to review every single WIP commit Do you usually review every commit? I usually just review the diff between the PR'd branch and master, as does everyone I work with.
  - pdimitar 5y ago
    Exactly, and that's why we use squashed commits.
    - user-the-name 5y ago
      Why? You don't need to. GitHub will show you that diff, git itself will show you that diff. There is no need to permanently rewrite history to do this. That makes no sense.
      - pdimitar 5y ago
        For the last time: squashed commits help teams who need the main branch be a high-level history of delivered features and fixed bugs. Where one commit is one delivered feature or a bug fixed. That's the idea. Whether you think that "makes no sense" is inconsequential. Many people find it very meaningful.

azernik 5y ago

That is absolutely what it's there for! git blame and git log are extremely commonly used, git bisect is only convenient in a commit history where breakage is uncommon, &c

user-the-name 5y ago
None of those require a "meaningful history that tells a bigger story".

pdimitar 5y ago

GitHub in particular is widely used by managers -- not the higher-level managers of course, but a lot of engineering managers have mastered the usage of GitHub issues, Markdown task lists inside PR descriptions, and reviewing results of CI/CD pipelines. And many tech leads simply don't have the time to review every single WIP commit. They want meaningful message/description of the big squashed PR commit. If you just post a merged list of all commit messages with 10x "fix stuff" inside you'll be in big trouble the next time around and your work will be inspected very closely. The practices I am describing to you are reality in many tech companies. Writing code there is not about you at all. And almost nobody will read your code and PR descriptions unless they really have to. Hence it's a professional courtesy to make those as small and meaningful as possible.

user-the-name 5y ago
> And many tech leads simply don't have the time to review every single WIP commit Do you usually review every commit? I usually just review the diff between the PR'd branch and master, as does everyone I work with.
- pdimitar 5y ago
  Exactly, and that's why we use squashed commits.
  - user-the-name 5y ago
    Why? You don't need to. GitHub will show you that diff, git itself will show you that diff. There is no need to permanently rewrite history to do this. That makes no sense.
    - pdimitar 5y ago
      For the last time: squashed commits help teams who need the main branch be a high-level history of delivered features and fixed bugs. Where one commit is one delivered feature or a bug fixed. That's the idea. Whether you think that "makes no sense" is inconsequential. Many people find it very meaningful.