<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 28 Dec 2018 at 02:13, akgrant43 <<a href="mailto:notifications@github.com">notifications@github.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <blockquote>
<p>Note that I like to see the "messy" decomposed history where each change<br>
has a rationale attached in a separate commit message.<br>
Of course, erratic trial and errors may benefit from a little rewrite of<br>
history, but not a squash, it's too violent for my taste, more something<br>
like a rebase -i.</p>
</blockquote>
<p>I think maybe we're saying the same thing.  Each commit in the main branch (Cog) should be single purpose and well documented, e.g. includes the rationale, which allows the reader to see the progression and consume the changes in small, understandable steps.  I'm just suggesting one way to achieve that.</p>
<p>Leaving a messy (i.e. something that includes a mistake) decomposed history can just lead to confusion, e.g. I recently didn't squash down one of my PR's.  Because it had every intermediate commit one reviewer thought I had committed a plugin built from dirty code, when in fact a later commit in the PR used clean code.</p></blockquote><div>I'm in full agreement.  Never a full squash, but trying to minimize the noise of "whoops" commits,</div><div>or like for the Freetype-2.9.1 windows build I'm working on, experimenting to understand differences between local and CI environment.</div><div><br></div><div>I support using `rebase -i`, but it can take a little practice, and there seems some fear floating around of losing code.</div><div>`git commit --amend` is a milder form that is only able to affect the previous commit.</div><div><br></div><div>cheers -ben</div></div></div>