Add Y-forking import project

[philderbeast]

Split from #9933, this adds just the project used for that pull request's test without adding any test or behaviour change in cabal.

[philderbeast]

@Mikolaj and @gbaz, I've added this for the reproduction of #10509. Please let me know if you'd like me to add a test for this project to cabal-testsuite/PackageTests/ConditionalAndImport/cabal.test.hs to record the current behaviour in the cabal.out file.

[Mikolaj]

Looks good. Re adding a test, sounds good too, but I don't quite grasp the question: are you asking whether we'd prefer you to add the test sooner rather than later? Or would the test be transient, because the behaviour would be changed soon? Generally, what are the alternatives you ask for recommendation about?

[philderbeast]

@Mikolaj, I've added a simple test that the project builds. That should do for now.

In future, I hope we can avoid the extra work of importing the same config multiple times and if we decide a project import tree like this, with multiple imports of the same .config file, is not an error then at least provide a warning about it.

[philderbeast]

Label merge+no rebase is necessary when the pull request is from an organisation.

[Mikolaj]

Makes sense. Thank you.

[philderbeast]

@Mikolaj this hasn't yet merged.

[Mikolaj]

Huh, I guess the push made the trick?

[philderbeast]

I wasn't expecting it to merge soon after rebasing. I was surprised that it wasn't reporting any problems before the rebase of today, being a week old. The test results were different. I have no idea why the merge was stuck where it was.

[geekosaur]

Because Mergify is currently configured to require any merge+no rebase PR to be up to date, because you would need to rebase it manually anyway.

[philderbeast]

Thanks @geekosaur for the explanation.