On Sat, 18 Apr 2026, Martin Frb via fpc-devel wrote:
On 18/04/2026 15:18, Michael Van Canneyt via fpc-devel wrote:
On Sat, 18 Apr 2026, Martin Frb via fpc-devel wrote:
On the last point: It may be that for you conflict resolution works
fine in the gitlab interface.
For me, that is - half the time - not the case.
We must have very different users.
I don't think even 3% neeed conflict resolution.
Misunderstanding....
Half of the time that need conflict resolution => Of those times that
need it, take half.
Well, since we don't do conflict resolution in gitlab, the point is moot.
If there is, most of the time user needs to take action.
It's very rare that I must do it.
For the current low amount of MR, indeed its rare.
But if you scale up the amount of MR by making all team commits go that
way, and therefore also touch a wider range of code => then it will
happen more often.
Why would that happen ?
The member pushing the MR can merge it as soon as he created it.
The point of the MR is to have a record of grouped commits that can easily
be flagged and merged later on.
Quite possible even between commits of the same person. => I have plenty
of conflicts between my own branches. (because by nature they work on
the same range of code / so if I do more than one thing at a time, then
conflicts are natural)
Makes no difference then. You'll have work either way.
I do regularly open conflicts (with the >>>> markers) in the IDE, and
resolve them there. It's just for me personally that works better in
those cases.
I never use gitlab to resolve conflicts. I do the same as you, but see
above.
Hope my new reply explains it better.
Considerably, yes.
----------------------
I am missing your response to the following.
Which is
- *NOT* about MR from 3rd party
It is about MR from 3rd party.
My point was that since we have gitlab, the merging of user contributions
goes way faster than the SVN+Mantis procedure, where we had to
download and apply patches manually. Anyone denying that is denying
the light of the sun.
Then we were talking about 2 diff things. I was under the impression
this was all still about the "every commit by every team member should
go via an MR".
It is. See below, integrator role.
Given the amount of work I do on MRs, if I can flag and later or
immediatly merge MRs to a fixes branch, it would be a huge time saver.
So if the team would also use MR's and just flag them 'fit for fixes'
then that should normally result in more regular releases for the users.
Is that you volunteering to look after the flagged commits?
yes, obviously. The role is usually called an integrator.
We do this integration today, manually. It's clearly not working.
By doing what I propose, the role of the integrator becomes much easier.
Or you expecting everyone to then search there flagged MR and deal with
them themself?
That would be utterly pointless.
And, if it is: everyone taking care of their own MR
=> then why doing an MR at all, why not just instantly cherry picking?
Indeed.
That what we (Lazarus) currently do (with slight extra for the few not
yet that comfy with git) => If someone commits something, and its fixes
worthy they cherry pick it.
That's why IMO the MR is better. if you have 10+ commits, you do it in one fell
swoop with the MR, and (a benefit IMO) it can be done by someone else
(the integrator). All the developer needs to do is merge and flag the MR.
An additional advantage of MR is also that we can run CI/CD once before merge;
doing CI/CD for every push is most likely not going to work any more once
we make the CI/CD work for all platforms. The allowed compute time is not
infinite, and as soon as a new push is done, an existing pipeline is
aborted, making error detection much harder. the gitlab mails which I
receive often indicate the wrong commit because of this.
Are there some extra steps for the dev ? Yes, obviously.
But if it results in more frequent releases, then IMO that's worth it.
Michael.
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
