

<HTML><BODY><div class="cl-hm9ymrvzla"><div class="js-helper_mr_css_attr js-readmsg-msg_mr_css_attr"><div id="style_17764572751077203416_mr_css_attr"><div id="style_17764572751077203416_BODY_mr_css_attr"><div class="cl-o0yjllqnko_mr_css_attr"><div class="mail-quote-collapse_mr_css_attr"><blockquote style="border-left:1px solid #0857A6;margin:10px;padding:0 0 0 10px">That's why there's extra effort on keeping the compiler's<br>history linear, avoiding merge commits and running regular automated<br>tests on many platforms, so that bugs are caught early and so that it is<br>easy to find the single commit that caused a bug via "git bisect". I've<br>worked commercially in my last job on a compiler for a specialized<br>language, called "Noir" that used a "squash" all merge request policy<br>and it didn't work well with regards to stability and ease of resolving<br>merge conflicts. But it was a "move fast and break things" kind of<br>startup mentality, so they didn't care much about stability at this stage.</blockquote></div></div><div> </div><div>Yes, squashing is «evil» - it's only needed to clean up the messy history of many small edits (if you were adding commits to the MR for editing instead of rebasing). I mentioned this in this comment:</div><div> </div><div><a href="https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/988#note_3241863181">https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/988#note_3241863181</a></div><div><br>It should be a regular merge, without squashing. This keeps the entire history intact (all commits, dates, etc.). We already discussed this in this issue:</div><div> </div><div><a href="https://gitlab.com/freepascal.org/lazarus/lazarus/-/work_items/42205">https://gitlab.com/freepascal.org/lazarus/lazarus/-/work_items/42205</a></div></div></div></div></div></BODY></HTML>