3 ms·

Because when debugging with said history a week or a month down the line, or when someone else is debugging with said history, their human comprehension is esse

Because when debugging with said history a week or a month down the line, or when someone else is debugging with said history, their human comprehension is essential for understanding why a certain event in the history is causing problems and what that event was intended to do.

user-the-name 5y ago
That seems connected to the initial claim in only the most tenuous way.
- azernik 5y ago
  In the Linux kernel mailing lists, which are the submit-by-email culture I'm most familiar with and with the best documentation of norms, the main criterion for individual patches is that they be comprehensible to a reviewer. Reviewers and bugfixers face similar reading comprehension constraints.
  - user-the-name 5y ago
    But why should any of that apply to my version control system? I'm not developing the Linux kernel on a mailing list.
    - pdimitar 5y ago
      It shouldn't for your personal stuff. But it absolutely should when you work in a team. I'll personally scold you if you waste my time with merging a 20 commit PR of which 10 commmits are "fix stuff" or "fix typo" or "oops forgot variable" etc. It won't pass code review. You are free to disagree. I am only telling you how it is in many companies.
      - user-the-name 5y ago
        But why? What problem are you actually solving with this?
        azernik 5y ago
        1. Waste of code reviewers' time 2. Waste of later coders' time when running git blame on a line when trying to figure out the purpose of code 3. Waste of later debuggers' time when they need to decide whether this error is the thing they're looking for, an unrelated error to bisect skip, or an unrelated error in possibly-related code that they need to manually fix and then re-test.
        pdimitar 5y ago
        As the other sibling poster says, it's about not wasting other people's time. Make the messages/descriptions ruthlessly short and to the point and your colleagues will like you.

user-the-name 5y ago

That seems connected to the initial claim in only the most tenuous way.

azernik 5y ago
In the Linux kernel mailing lists, which are the submit-by-email culture I'm most familiar with and with the best documentation of norms, the main criterion for individual patches is that they be comprehensible to a reviewer. Reviewers and bugfixers face similar reading comprehension constraints.
- user-the-name 5y ago
  But why should any of that apply to my version control system? I'm not developing the Linux kernel on a mailing list.
  - pdimitar 5y ago
    It shouldn't for your personal stuff. But it absolutely should when you work in a team. I'll personally scold you if you waste my time with merging a 20 commit PR of which 10 commmits are "fix stuff" or "fix typo" or "oops forgot variable" etc. It won't pass code review. You are free to disagree. I am only telling you how it is in many companies.
    - user-the-name 5y ago
      But why? What problem are you actually solving with this?
      - azernik 5y ago
        1. Waste of code reviewers' time 2. Waste of later coders' time when running git blame on a line when trying to figure out the purpose of code 3. Waste of later debuggers' time when they need to decide whether this error is the thing they're looking for, an unrelated error to bisect skip, or an unrelated error in possibly-related code that they need to manually fix and then re-test.
      - pdimitar 5y ago
        As the other sibling poster says, it's about not wasting other people's time. Make the messages/descriptions ruthlessly short and to the point and your colleagues will like you.