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.
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
