5 ms·

Have you ever tried following a change in a repo that came from an unsquashed PR? It's hell. What's truly meaningful IMO is a git log that reads like a product

by kylnew 11y ago

Have you ever tried following a change in a repo that came from an unsquashed PR? It's hell. What's truly meaningful IMO is a git log that reads like a product change log

WorldMaker 11y ago
«Have you ever tried following a change in a repo that came from an unsquashed PR?» I have a self-congratulating black belt in source code archeology. With the right tools, most of which are on GitHub, even, such as good commit range diffing, smart uses of tags and branches, and knowing how to navigate the DAG from merge commits (more reason to -no-ff) you have a lot of power in your hands. «What's truly meaningful IMO is a git log that reads like a product change log» I appreciate that point of view, but I don't share it. A product change log, I feel, is a bit of marketing/PR that needs some time, love, and editing; I find a git log is for catching snapshots of raw progress and more often useful in seeing what your co-developers are up to, as they are working.
- kylnew 11y ago
  I think this really comes down to team. It's kind of an all-in or nothing thing and if you go against the grain everyone will just end up angry
  - WorldMaker 11y ago
    Absolutely, not every team follows the same preferences, so with any style/aesthetic choices, be sure to know what the team zeitgeist is. (I'm not a monster, I play well on teams, I promise.)
- natrius 11y ago
  Try it both ways. I used to agree with you until I tried squashing after code review.
teacup50 11y ago
As someone who has spent a lot of time tracking down the origin of source code changes -- and the reasons for them, and the implications of the change -- by reviewing commit logs, I can think of little worse, short of no commit history at all, than trying to derive anything remotely useful from a commit history that has been condensed down to a product change log. Even commits that lack good commit messages provide valuable information in the form of insight into the author's cumulative thinking/process.
- kylnew 11y ago
  Ugh, the thought of scouring through commits with messages like "fixed", "oops", "done" is like fingernails on a chalkboard to me. What I read is a LACK of thought process, when you can't squash and justify your changes susinctly

by kylnew 11y ago

Have you ever tried following a change in a repo that came from an unsquashed PR? It's hell. What's truly meaningful IMO is a git log that reads like a product change log

WorldMaker 11y ago

«Have you ever tried following a change in a repo that came from an unsquashed PR?» I have a self-congratulating black belt in source code archeology. With the right tools, most of which are on GitHub, even, such as good commit range diffing, smart uses of tags and branches, and knowing how to navigate the DAG from merge commits (more reason to -no-ff) you have a lot of power in your hands. «What's truly meaningful IMO is a git log that reads like a product change log» I appreciate that point of view, but I don't share it. A product change log, I feel, is a bit of marketing/PR that needs some time, love, and editing; I find a git log is for catching snapshots of raw progress and more often useful in seeing what your co-developers are up to, as they are working.

kylnew 11y ago
I think this really comes down to team. It's kind of an all-in or nothing thing and if you go against the grain everyone will just end up angry
- WorldMaker 11y ago
  Absolutely, not every team follows the same preferences, so with any style/aesthetic choices, be sure to know what the team zeitgeist is. (I'm not a monster, I play well on teams, I promise.)
natrius 11y ago
Try it both ways. I used to agree with you until I tried squashing after code review.

teacup50 11y ago

As someone who has spent a lot of time tracking down the origin of source code changes -- and the reasons for them, and the implications of the change -- by reviewing commit logs, I can think of little worse, short of no commit history at all, than trying to derive anything remotely useful from a commit history that has been condensed down to a product change log. Even commits that lack good commit messages provide valuable information in the form of insight into the author's cumulative thinking/process.

kylnew 11y ago
Ugh, the thought of scouring through commits with messages like "fixed", "oops", "done" is like fingernails on a chalkboard to me. What I read is a LACK of thought process, when you can't squash and justify your changes susinctly