Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

• Always add tests
• Keep backward compatibility (see https://symfony.com/bc).
• Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
• Features and deprecations must be submitted against the 7.2 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

Looking at https://docs.docker.com/compose/compose-file/13-merge/#replace-value, they use a yaml tag for this.
Is that something we could do also?

Hi @nicolas-grekas 🙋🏼‍♂️,

thanks for looking at my PR :). I believe we're able to handle it similarly. My way was easier and universal across all config formats. In such way, we should handle it like:

YAML:

#...
from: !override
	- from_a
	- from_b

PHP:

	->override()

XML:

	<... override="true">

I'll try to implement this 🧐.

The merging happens during the processing of the configuration in the DI extension (based on the Configuration class). So it would be hard to use such Yaml tags for that.

I would say that from places for a workflow transition should never be merged between different files redefining the transition, which would be doable by using the ->performNoDeepMerging() in the Configuration class. In the old days of Symfony, we were careful about where merging should happen in our configuration and where it should be disabled. I have the feeling that this was less considered in more recent times, which means we should probably review our Configuration to identify places where deep merging does not make sense.

Closing in favor of #61757 per @stof's comment. Thanks for raising this point.