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

[Marco van de Voort]

Op 7-4-2026 om 13:36 schreef Martin Frb via fpc-devel:
>
> 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 it is a pure fix, maybe. If it is part of a restructure, that is harder.

> 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.

I hardly can leave commits in local repos for long, as I work on 
multiple machines, so that would not be an option for me.

Yes, I know I can invest an insane amount of time to interface it via my 
own gitlab repository, but that would only be more work, both in setting 
up as in daily use.

> 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.
IMHO only if you fully follow the git suggested workflow to the letter. 
As soon as your workflow situation differs, the whole thing comes 
crashing down. IMHO git has the doubtful attribute of being both too 
flexible and too inflexible at the same time.
>> 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.

There is IMHO still a big difference between immediate and after a few 
weeks. The need for immediate merging action without first seeing how it 
fares in main is IMHO too limited.  That is the whole idea of having two 
branches.

>> 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...

There are a handful of regular fix submitters (among others Margers, 
Rika, AlexTP, Gareth as the most frequent) that deliver to the point 
fixes.  And maybe it is easier that way than the old way of giving them 
commit bits with some warnings (like don't commit outside of your 
expertise without review).

That is the netto plus saving some commit account administration maybe, 
and a bit of control/oversight. But that doesn't really broaden the 
contributing developers as much as often was predicted.

So I stand by my conclusion that it is not  the landslide feature as it 
was made out to be.

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

Yes. Roughly the same trick as with old style patches too, together with 
manually removing often conflicted but trivial bits like Lazarus 
projects and makefiles.

>> 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.

How do you enforce that? A post commit script at gitlab that updates and 
the squashes the commits into one?

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

I think the main reason is to be able to check out the multiple repos 
(that are IMHO separate administrative units) as one checkout with one 
branch name. E.g. for release and snapshot scripting. Also in the past, 
fpcdocs was versioned, that might also have been a factor. (the fixes 
fpcbuild links to the fixes docs).  You could switch the version of the 
docs on a per branch basis (for trunk-fixes-release candidate-release).

I might be doing something wrong but iirc this didn't work for me on 
windows for RC1 and ended up  hand copying repos in each other to get a 
buildable complete tree, so the current situation is not ideal.

Anyway I'm not entirely sure what the original reason was.  I wasn't 
much involved in the early SVN migration on an architectural level, more 
on keeping things going, like I'm now with git.  But I used a much 
larger subset of SVN than I ever did of CVS because of the merge/release 
work and  the various packages/ restructures. SVN felt an improvement 
pretty quickly (if only because renaming files was easier)

If git is too inflexible, I rather would lean towards adapting those 
scripts for multiple checkouts than stuff everything in one repo. But 
that depends on my guestimate on the reasons, and might require careful 
synchronizing branch names between repos, so that you can check them all 
out with one branch name.

And as said I think there was an element of pacing the migration changes 
but that petered out.

> There are very few commits to fpc-build (other than the robo ones). 

That's because there have been no releases. It usually picks up around 
release time and during the year that a major branch is in beta.

> 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... 

... but I agree this could all be overcome if the submodule construct is 
too hard over time. It is from a different magnitude than e.g. the merge 
tracking.