Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Console] Don't load same-namespace alternatives on exact match #35696

Merged
merged 1 commit into from Feb 13, 2020

Conversation

chalasr
Copy link
Member

@chalasr chalasr commented Feb 13, 2020

Q A
Branch? 3.4
Bug fix? yes
New feature? no
Deprecations? no
Tickets Fix #35479
License MIT
Doc PR -

@fabpot
Copy link
Member

fabpot commented Feb 13, 2020

Thank you @chalasr.

fabpot added a commit that referenced this pull request Feb 13, 2020
…match (chalasr)

This PR was merged into the 3.4 branch.

Discussion
----------

[Console] Don't load same-namespace alternatives on exact match

| Q             | A
| ------------- | ---
| Branch?       | 3.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | Fix #35479
| License       | MIT
| Doc PR        | -
<!--
Replace this notice by a short README for your feature/bugfix. This will help people
understand your PR and can be used as a start for the documentation.

Additionally (see https://symfony.com/roadmap):
 - Always add tests and ensure they pass.
 - Never break backward compatibility (see https://symfony.com/bc).
 - Bug fixes must be submitted against the lowest maintained branch where they apply
   (lowest branches are regularly merged to upper ones so they get the fixes too.)
 - Features and deprecations must be submitted against branch master.
-->

Commits
-------

707c5ba [Console] Don't load same-namespace alternatives on exact match found
@fabpot fabpot merged commit 707c5ba into symfony:3.4 Feb 13, 2020
@stof
Copy link
Member

stof commented Feb 13, 2020

shouldn't the case of exact-match be handled much earlier, before computing $allCommands ? that's where this is handled for non-lazy commands, but the command loader is not checked there.

@chalasr
Copy link
Member Author

chalasr commented Feb 13, 2020

@stof Returning early in case of exact match has been done as an optimization for 4.4 while this targets 3.4, if that's what you mean. And we may want to backport it instead, indeed.
But note that right now, nothing forbids to call setAliases() from a lazy command, even if it's broken as such aliases aren't displayed with list. This PR stays relevant for this case

@chalasr chalasr deleted the fix-same-ns-laziness branch February 13, 2020 17:32
chalasr added a commit that referenced this pull request Feb 15, 2020
This PR was merged into the 3.4 branch.

Discussion
----------

[Console] Inline exact-match handling with 4.4

| Q             | A
| ------------- | ---
| Branch?       | 3.4
| Bug fix?      | no
| New feature?  | no
| Deprecations? | no
| Tickets       | #35696 (comment)
| License       | MIT
| Doc PR        | -

This reduces the patch for #35696 (not released yet), inlining 3.4's code with 4.4 which was not impacted by the fixed bug. The reverted logic was useless starting from 4.4.
Thanks @stof for the hint.

Commits
-------

e13470c [Console] Inline exact-match handling with 4.4
This was referenced Feb 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants