>> As a told you: Let's assume MR #1 contains commits a, b, c, and MR
>> #2 commits d, e, f, and MR #2 depends on MR #1. To make the
>> pipeline run successfully for MR #2, copy commits a, b, c so that
>> MR#2 actually consists of a, b, c, d, e, f. This is tedious and
>> awkward to manage, I know, but better than waiting IMHO.
>
> Uh, there is a hard dependency. Of course the merge request branch
> contains all relevant commits. The diff is against its dependent
> branch which makes reviewing for humans easy, the snapshot contains
> every necessary change, and it is rebased so that exactly the same
> commits as the parent merge request branch are in the ancestry and
> of course in every work tree checkout.
>
> I think we are talking past one another. You can perfectly well
> check out merge request branch 3115 and compile it, and it will
> contain every single change in branch 3111 and every commit as well.
Yeah, I know that. And still, gitlab apparently doesn't allow CI to
take care of this situation, thus my work-around suggestion.
Maybe it is posible with some special code in the CI configuration for
LilyPond's git repository, I really don't know. Asking a search
machine didn't reveal anything that I can understand.
Werner
