Re: How to do add-on merge requests and get a pipeline to run?

Jonas Hahnfeld via Discussions on LilyPond development
<[email protected]> writes:

> On Tue, 2026-08-11 at 22:54 +0200, David Kastrup wrote:
>> Jonas Hahnfeld <[email protected]> writes:
>> > In my personal opinion, this is (or should be) a rather exceptional
>> > case since incremental development should be incrementally submitted
>> > and reviewed, at a sustainable pace, and with the possibility of
>> > incorporating review feedback from earlier merge requests.
>> 
>> [...]
>> 
>> > If you have more changes already submitted, that will only result in
>> > endless conflicts...
>> 
>> Stacking MRs actually seem like a reasonable way to keep the number of
>> conflicts down over having diverging commits in two separate MRs one of
>> which is the base for another.
>
> I think the conflicts will occur either way. Say we have branchA and
> branchB, and there is already a merge request A with branchA to master.
> Now branchB will have the same commits regardless of whether merge
> request B targets branchA (stacked MR) or master directly (dependent
> MR). Either way, making changes in branchA will require conflict
> resolution in branchB and a second push to merge request B. What
> changes is just how the MR is displayed in the UI.

But that is the point.  A review works by going through the changes, and
a stacked merge request only displays the differential changes.

That makes the stacked requests separately reviewable.  The branch
constituents in terms of commits are the same regardless of what branch
the MR is based off , but the reference point for the reviewable changes
is a different one.

For reviewing single commits, you can just constrain yourself to the
commits of interest.  For doing a review on the actually relevant
changes, the difference is quite helpful.

-- 
David Kastrup