On 4/17/26 5:10 PM, Michael Van Canneyt via fpc-devel wrote:
On Fri, 17 Apr 2026, Nikolay Nikolov via fpc-devel wrote:
On 4/17/26 4:32 PM, Graeme Geldenhuys via fpc-devel wrote:
On 2026-04-17 13:00, Marco van de Voort via fpc-devel wrote:
And then we still have to find out if that concept works at all in
the FPC context.
And yet it works flawlessly on 10,000s of other open source projects
(big and small). I simply don't know why you think FPC is so special
that it will not work here.
FPC is special in the regard that it is a compiler and that it has an
extremely high coupling between compiler and rtl units. So, changes
are very interdependent. It's hard to separate them and treat them as
independent, because they're simply not.
So ? How is the proposed flow at odds with this ?
I would think rather the opposite: by doing a MR you ensure related
commits remain together.
I'm not sure I understand the question. Graeme's proposal includes
squashing commits. Squashing rewrites history and converts many commits
into one. Currently, the "eliminate_global_state" branch contains 1080
commits. All of these will be merged into one. Then, if it turns out
this breaks some obscure platform in a weird way, we'll have an "all or
nothing" approach - revert everything, or keep it broken. You won't have
any idea which of these 1080 fine grained commits really caused this bug.
Or, are you talking about something else?
The problem with git is that there are so many workflows possible and
that no two developers can agree which subset of it to use.
Nikolay
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
