On 17/04/2026 16:06, Michael Van Canneyt via fpc-devel wrote:
On Fri, 17 Apr 2026, Michael Van Canneyt via fpc-devel wrote:
----------
But the core idea (if that does not already happen?):
When a commit makes it into main, decide then and there if that
commit may (maybe) go into any fixes branch. (does not cover any
dependencies, just the commits that of their own accord want to be
in fixes).
-> hence the milestone. when you create the MR, you decide if it is
'merge-worthy' and add the milestone. Later on you have 99% of your
list for
free.
I was wondering why there is so much resistance to this idea, why people
think it is cumbersome.
There is a detail that is maybe unknown to erstwhile SVN users:
When you look at a MR that was merged to devel, there is a link
'Cherry pick'
in the MR gitlab page. This will let you merge all commits of the MR to
another branch (fixes or any other).
This literally lets you merge a MR to another branch with some clicks.
No need for checkouts, merging manually, pushing etc.
It can be done when a MR was just merged to devel, or can be done
later on.
In case of conflicts, it's of course a little more work, but this has
always been so.
But in the bulk of cases, it's just a couple of clicks and you're done.
Well, see my other mail...
But lets differentiate.
If I merged a contributed MR... And if I did that online... I have no
issue to use the web to cherry pick it to fixes too.
(some MR I prefer to pull, and merge locally, and test (or add commits)
before I push).
If I do my own commits (even If it was decided that every change, even
single commits changes would go through a branch), then I would want to
merge those branches locally.
Going to the web interface requires me to involve an additional tool,
switching to my browser, needing my browser to go to another tab, ...
It may just be a few clicks. Its still less if I do it locally.
Also, given that I may have more than one branch in the works (that
happens, even now, when I rebase everything on top of main), then
switching tools adds a danger of having the wrong branch in the tool,
and acting on the wrong branch.
That has happened locally too. But locally that is not an issue (well,
its time lost, but all else recoverable). Locally I have the reflog, and
can rewrite everything to what it should be.
--------------------
further doing my fixes-merges locally has advantages when I defer
pushing them, wanting to wait if any issues are reported on main.
I then just have un-pushed commits on my local fixes branch, and rebase
them when needed. But I have them all in one place, and ready to push.
I find that by miles more convenient than having to search gitlab for MR
that
- are mine
- merged to main
- milestoned for fixes
- not yet in fixes
But on that last bit, I don't know, maybe gitlab has some bits to ease
that (unlikely it will be as simple as my "git log fixes", but still.
I have to say, after all I am more of a git guy, than a gitlab guy.
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
