[fpc-devel] [RFC] Modernising the FPC Release Process -- Proposal for Review

[n7800]

> 
> That's why there's extra effort on keeping the compiler's
> history linear, avoiding merge commits and running regular automated
> tests on many platforms, so that bugs are caught early and so that it is
> easy to find the single commit that caused a bug via "git bisect". I've
> worked commercially in my last job on a compiler for a specialized
> language, called "Noir" that used a "squash" all merge request policy
> and it didn't work well with regards to stability and ease of resolving
> merge conflicts. But it was a "move fast and break things" kind of
> startup mentality, so they didn't care much about stability at this stage.

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:

https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/988#note_3241863181

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:

https://gitlab.com/freepascal.org/lazarus/lazarus/-/work_items/42205
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20260417/d06b3544/attachment-0001.htm>