[fpc-devel] 134 open merge requests - is that normal?

[Martin Frb]

On 07/04/2026 12:41, Marco van de Voort via fpc-devel wrote:
>
>
>> But, with git everybody should become part of it. Ok, well not 
>> everybody will feel comfortable enough, but that is solvable, if at 
>> least half of the team has the "git knowledge" (and willingness).
>>
>> Everyone should make a **pre**-selection of their own commits in 
>> terms of merge or not. 
>
> Yes. But that could have been done both with past SVN or current 
> git-with-patchy mergetracking. It simply doesn't happen.
>
> That is the whole problem with all these fantasies (the git migration 
> inclusive), they paint an ideal sunny upland, and then try to simplify 
> the whole issue to "if we just cross this bridge, the problems will be 
> gone away". But the devil is in the details, and it is usually the 
> human factor. The big changes are only goal posts to nail policy too, 
> they don't solve anything in itself.

Well, what I can say for myself (slightly modified for those less git 
experienced). If I make a commit, that I deem might be a fix => I can 
immediately make a local cherry pick.
If there are conflicts, they will be best solved when my memory is 
fresh, and in doubt I write the changes anew into the cherry pick.

I don't have to push that. I can keep it until I know I want to push it. 
(I can also push it elsewhere and ask for review).
If there is other incoming on the branch, while I haven't pushed, the 
conflicts with that are usually smaller.

And if you need a final selection, you can cherry pick from the cherry 
picks...

IMHO git offers some small additions over SVN here. But the real 
advantage only comes if everyone participates.

Those less experienced can ask for their commits to be merged by others 
in the team. If done regularly that will be a minimum burden. They may 
still need to answer and be involved if there are conflicts.



>
> To be fair: merging in the compiler is harder than what I do , since 
> things are more interconnected there.
Which imho makes it even more important to merge/pick "potential fixes" 
asap. Once you start forgetting all the nitty gritty of your change, 
picking them becomes much harder.

If needs must, pick into an intermediate branch, and pick a 2nd time later.

>
>>> Florian already mentioned the submodule problems.
>>
>> Leaves the question why they are not re-organized.
>
> Because we were told that git solves all problems and can do 
> everything (;-)).  It was all so simple and modern, and contributors 
> would magically appear from all corners of the internet, and pink 
> unicorns would run through its streets and fart perfect code. (ok, I 
> made that last bit up)
Well, unicorns need a handler that guides them. ;)

> Well, merge requests is  the original subject of this thread. One can 
> argue if they are a netto plus or not, but there are downsides too (it 
> allows users to submit more code at once and without prior 
> communication to core about formatting and other decisions), and in 
> any case they are not the game changer they were hailed to be.
>
> (I think they are a netto plus, but a rather small one)
They are on the attract others side...

Though, there is a need "trick" to deal with older MR (also can be done 
for patches and all).

Apply them to a revision of the time when they originated, then rebase 
them forward step by step => each time you get to solve a small set of 
the conflicts. It does take longer, but you see the smaller conflicts 
that may be easier to identify how to solve (not always / sometimes)


>
> Anyway, if we reverse the order, then if I understand everything 
> correctly  we would have the robo commits to advance the fpcbuild 
> submodule link in the fpc/ repo ? No thanks!
Ideally the would be part of the commits that would make them a requirement.

Well depends...

If FPC-build changes to accommodate a new version of "make" then yes.
But, if you add stuff to fpc-source that needs changes in the build 
process, then that should be one commit.

The robo-commits basically signify that they are one single repo. The 
split is arbitrary, the could be all in one git repo.

There are very few commits to fpc-build (other than the robo ones). And 
how many of those real commits are because a commit to fpc-source made 
them necessary (and therefore the reversed submodule update in 
fpc-source to pull a newer fpc-build) could have been part of the 
overall commit?


But then again, as I don't use them, I really don't know all the 
requirements...