<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>sulam</author><text>caveat: I was responsible for code review for 2000+ developers.&lt;p&gt;We only allowed squash commits on master because of what you&amp;#x27;re describing. That is the level where history &amp;quot;made sense&amp;quot;. However, for code review, we wanted to support both styles, because there is an advantage sometimes to seeing the sausage being made. For instance someone will refactor something -- maybe change a method name. Then they apply that refactoring at all the call sites. Very conscientious developers would break this into two commits. We didn&amp;#x27;t want the first commit on master, but it made sense to &lt;i&gt;review&lt;/i&gt; this way, because it was easier on the reviewers: change, effect of change on everything else.&lt;p&gt;I call this &amp;quot;telling a story&amp;quot; with your commits. There&amp;#x27;s a lot of value in that style if you have the time to do it.&lt;p&gt;The other style of commit-by-commit reviewing, where I see all of the work in progress commits, I don&amp;#x27;t find valuable at all and I _definitely_ don&amp;#x27;t want to see on master.</text><parent_chain><item><author>phasmantistes</author><text>I actually disagree. Large teams that still have linear commit histories doesn&amp;#x27;t mean it is a lie. It means that the &lt;i&gt;code review&lt;/i&gt; process is more important that the &lt;i&gt;code writing&lt;/i&gt; process.&lt;p&gt;For example: I check out a repository, and create a local feature branch. I create a commit containing the tests for the new feature, then one for the first draft of the new feature, then two or three for bugfixes. Each commit is small, and self-contained, but importantly &lt;i&gt;isn&amp;#x27;t standalone&lt;/i&gt;. If someone checked out the repository in the middle of my chain of commits, they wouldn&amp;#x27;t have a working product. Then I upload my change for code review. There&amp;#x27;s no point in reviewing each of my ~5 commits individually: they only make sense to the reviewer as a combined unit. And there&amp;#x27;s no point in landing them individually: they only make sense for the overall project history as a combined unit.&lt;p&gt;In a project with many developers (e.g. 1,000 like the Chromium project), every developer has different local practices. Some keep their work based on HEAD of master via rebase, others via merges. Some do test-driven development, some don&amp;#x27;t. Making the code review the atomic unit of work, rather than the messy string of local commits, helps the project enforce common etiquette, commit formatting, and readable history.</text></item><item><author>WorldMaker</author><text>Sometimes I feel like it&amp;#x27;s a minority position, but I think it strange all the efforts people go to in order to essentially make the git DAG look like a (lie of a) straight-line CVS or SVN commit list. Seeing how the sausage was actually made (no rebases, no squashes, sometimes not even fast-forwards) isn&amp;#x27;t pretty, but it is &lt;i&gt;meaningful&lt;/i&gt; and will tell you a great deal about a project and its developers... I trust that. It&amp;#x27;s real and visceral and how software is actually made and you can learn from that or find things to explore in that jungle. Projects with multiple developers that yet have straight line commit histories and super tidy commits are aberrations and full of little lies...&lt;p&gt;Kudos to GitHub for providing this feature that a lot of people have asked for. I obviously don&amp;#x27;t plan to use it, but I appreciate that it&amp;#x27;s an option for those people that like their small, harmless lies. ;)</text></item></parent_chain></comment><story><title>Squash your commits</title><url>https://github.com/blog/2141-squash-your-commits</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>jldugger</author><text>&amp;gt;  It means that the code review process is more important that the code writing process.&lt;p&gt;If that were true, the optimal solution is PRs with individual commits that all pass testing. I find it much easier to review a series of small changes for logical correctness than mashing them together into a single PR. Github recently added this as a feature, so I&amp;#x27;m not in a completely invisible minority there.&lt;p&gt;And then, when the review is over, having discreet commits makes git bisecting down to the commit that broke the system more granular.</text><parent_chain><item><author>phasmantistes</author><text>I actually disagree. Large teams that still have linear commit histories doesn&amp;#x27;t mean it is a lie. It means that the &lt;i&gt;code review&lt;/i&gt; process is more important that the &lt;i&gt;code writing&lt;/i&gt; process.&lt;p&gt;For example: I check out a repository, and create a local feature branch. I create a commit containing the tests for the new feature, then one for the first draft of the new feature, then two or three for bugfixes. Each commit is small, and self-contained, but importantly &lt;i&gt;isn&amp;#x27;t standalone&lt;/i&gt;. If someone checked out the repository in the middle of my chain of commits, they wouldn&amp;#x27;t have a working product. Then I upload my change for code review. There&amp;#x27;s no point in reviewing each of my ~5 commits individually: they only make sense to the reviewer as a combined unit. And there&amp;#x27;s no point in landing them individually: they only make sense for the overall project history as a combined unit.&lt;p&gt;In a project with many developers (e.g. 1,000 like the Chromium project), every developer has different local practices. Some keep their work based on HEAD of master via rebase, others via merges. Some do test-driven development, some don&amp;#x27;t. Making the code review the atomic unit of work, rather than the messy string of local commits, helps the project enforce common etiquette, commit formatting, and readable history.</text></item><item><author>WorldMaker</author><text>Sometimes I feel like it&amp;#x27;s a minority position, but I think it strange all the efforts people go to in order to essentially make the git DAG look like a (lie of a) straight-line CVS or SVN commit list. Seeing how the sausage was actually made (no rebases, no squashes, sometimes not even fast-forwards) isn&amp;#x27;t pretty, but it is &lt;i&gt;meaningful&lt;/i&gt; and will tell you a great deal about a project and its developers... I trust that. It&amp;#x27;s real and visceral and how software is actually made and you can learn from that or find things to explore in that jungle. Projects with multiple developers that yet have straight line commit histories and super tidy commits are aberrations and full of little lies...&lt;p&gt;Kudos to GitHub for providing this feature that a lot of people have asked for. I obviously don&amp;#x27;t plan to use it, but I appreciate that it&amp;#x27;s an option for those people that like their small, harmless lies. ;)</text></item></parent_chain></comment><story><title>Squash your commits</title><url>https://github.com/blog/2141-squash-your-commits</url></story>