4 ms·

I don't know how people are programming. I have good unit tests and regression tests and even though I commit frequently, most of the time I don't end up with s

I don't know how people are programming. I have good unit tests and regression tests and even though I commit frequently, most of the time I don't end up with single purpose commits and usually when I trace back commit history these single purpose commits don't help me much, even if the team mates were writing commit messages like these. How much time do people spend to put too changes they did almost at once to make the code compile or the tests pass into two commits? Much more valuable are larger commits at the size of a small PR.

MrBuddyCasino 8y ago
I don’t understand why the history of the code matters so much to some people. Give me well designed and commented (!) code, with tests, designed to be understood by humans. Thats a bar few code bases clear, if I need to look at the git history its a sign the code is crap and I have to use all the information that I can get, with history being my least favorite because it has shitty UX (discoverability, navigation).
- schroffl 8y ago
  Having properly separated and single-purpose commits is awesome when running `git bisect` [1] — especially with automatic tests. As well when you revert said commits after the offender is found. [1]: https://git-scm.com/docs/git-bisect https://git-scm.com/docs/git-bisect
  - marcinzm 8y ago
    If you're using a CI that runs on every PR/master merge wouldn't it catch this without the need for git-bisect?
    - int_19h 8y ago
      Only if your tests have perfect coverage. And by "perfect" I don't mean lines or branches, but program states.
- marcinzm 8y ago
  >commented (!) code, Comments become stale and will often not be updated as the code changes.
  - MrBuddyCasino 8y ago
    This is what code reviews are for. Why would you exclude comments from that? It certainly doesn't happen in our team.
    - patrec 8y ago
      Comments often refer to stuff that's not directly in the "review window" i.e. the actual diff plus additional context you'll see in a typical code review setup. So even if people are conscientious about reviewing comment changes (and absence thereof!), too this often gets missed.
- u801e 8y ago
  > I don’t understand why the history of the code matters so much to some people. Having the git blame output of the line I'm changing is very helpful when determining the potential consequences of changing that line. If the history doesn't matter, then why bother with commit messages at all. You could essentially script your editor to run "git commit -a --allow-empty --allow-empty-message" every time you write the files to disk.
  - MrBuddyCasino 8y ago
    Our workflow is: - branch - commit first version, open Github PR with a text describing the PR, which is usually longer than the git commit message and contains links to notion pages and other things detailing the design - reviewers look at the code, and there is some to and fro with smaller commits until the PR is fine - code gets merged So the main action happens outside of git. Maybe for other workflows git commit messages are more important.
- int_19h 8y ago
  As time passes, practically no actively maintained codebase is going to clear your bar. It's going to pass through several different teams, with different policies and standards. Eventually, parts of it are going to be put on life support, which generally means an understaffed team that scrambles to patch up the most egregious bugs, often with dirty hacks, because they have no time and resources to do massive rewrites that are necessary to fix things properly. Maintaining such codebases requires a lot of "code archeology", and good history makes it much, much easier.
  - MrBuddyCasino 8y ago
    Not sure I get your point. People will cut corners and mess up the code, but somehow the history could be excempt from this?

MrBuddyCasino 8y ago

I don’t understand why the history of the code matters so much to some people. Give me well designed and commented (!) code, with tests, designed to be understood by humans. Thats a bar few code bases clear, if I need to look at the git history its a sign the code is crap and I have to use all the information that I can get, with history being my least favorite because it has shitty UX (discoverability, navigation).

schroffl 8y ago
Having properly separated and single-purpose commits is awesome when running `git bisect` [1] — especially with automatic tests. As well when you revert said commits after the offender is found. [1]: https://git-scm.com/docs/git-bisect https://git-scm.com/docs/git-bisect
- marcinzm 8y ago
  If you're using a CI that runs on every PR/master merge wouldn't it catch this without the need for git-bisect?
  - int_19h 8y ago
    Only if your tests have perfect coverage. And by "perfect" I don't mean lines or branches, but program states.
marcinzm 8y ago
>commented (!) code, Comments become stale and will often not be updated as the code changes.
- MrBuddyCasino 8y ago
  This is what code reviews are for. Why would you exclude comments from that? It certainly doesn't happen in our team.
  - patrec 8y ago
    Comments often refer to stuff that's not directly in the "review window" i.e. the actual diff plus additional context you'll see in a typical code review setup. So even if people are conscientious about reviewing comment changes (and absence thereof!), too this often gets missed.
u801e 8y ago
> I don’t understand why the history of the code matters so much to some people. Having the git blame output of the line I'm changing is very helpful when determining the potential consequences of changing that line. If the history doesn't matter, then why bother with commit messages at all. You could essentially script your editor to run "git commit -a --allow-empty --allow-empty-message" every time you write the files to disk.
- MrBuddyCasino 8y ago
  Our workflow is: - branch - commit first version, open Github PR with a text describing the PR, which is usually longer than the git commit message and contains links to notion pages and other things detailing the design - reviewers look at the code, and there is some to and fro with smaller commits until the PR is fine - code gets merged So the main action happens outside of git. Maybe for other workflows git commit messages are more important.
int_19h 8y ago
As time passes, practically no actively maintained codebase is going to clear your bar. It's going to pass through several different teams, with different policies and standards. Eventually, parts of it are going to be put on life support, which generally means an understaffed team that scrambles to patch up the most egregious bugs, often with dirty hacks, because they have no time and resources to do massive rewrites that are necessary to fix things properly. Maintaining such codebases requires a lot of "code archeology", and good history makes it much, much easier.
- MrBuddyCasino 8y ago
  Not sure I get your point. People will cut corners and mess up the code, but somehow the history could be excempt from this?