Rewrite "bashbrew children" and "bashbrew parents"#55
Merged
yosifkit merged 1 commit intodocker-library:masterfrom Nov 16, 2022
Merged
Rewrite "bashbrew children" and "bashbrew parents"#55yosifkit merged 1 commit intodocker-library:masterfrom
yosifkit merged 1 commit intodocker-library:masterfrom
Conversation
tianon
force-pushed
the
parent-children-rewrite
branch
2 times, most recently
from
c217aca to
9793925
Compare
Member
Author
|
(this also bumps our minimum Go version to 1.18+) |
tianon
force-pushed
the
parent-children-rewrite
branch
from
9793925 to
b6bae37
Compare
tianon
force-pushed
the
parent-children-rewrite
branch
from
b6bae37 to
1d99523
Compare
This time, they are distinct implementations because the problem they are solving is inherently different. For listing children of a given name, we *have* to walk the entire library (since we only have tag -> FROM mappings, not the reverse, which is fundamentally the question that "children" answers). On the flip side, listing the parents of a given name is as straightforward as looking up the FROM values and walking until we can't anymore. In my own testing, these new implementations are significantly more correct, and handle more edge cases (including things we couldn't support before like `bashbrew children --depth=1 scratch`, `bashbrew children mcr.microsoft.com/windows/servercore`, etc). They also more correctly handle edge cases like tags that are `FROM` a "`SharedTag`" such that they don't walk up/down both sides of the tree (for example, `orientdb:3.2` -> `FROM eclipse-temurin:8-jdk`, which is both Windows *and* Linux, even though `orientdb:3.2` is Linux-only).
tianon
force-pushed
the
parent-children-rewrite
branch
from
1d99523 to
f54c8e3
Compare
yosifkit
approved these changes
Nov 16, 2022
This was referenced Nov 16, 2022
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This time, they are distinct implementations because the problem they are solving is inherently different.
For listing children of a given name, we have to walk the entire library (since we only have tag -> FROM mappings, not the reverse, which is fundamentally the question that "children" answers).
On the flip side, listing the parents of a given name is as straightforward as looking up the FROM values and walking until we can't anymore.
In my own testing, these new implementations are significantly more correct, and handle more edge cases (including things we couldn't support before like
bashbrew children --depth=1 scratch,bashbrew children mcr.microsoft.com/windows/servercore, etc).They also more correctly handle edge cases like tags that are
FROMa "SharedTag" such that they don't walk up/down both sides of the tree (for example,orientdb:3.2->FROM eclipse-temurin:8-jdk, which is both Windows and Linux, even thoughorientdb:3.2is Linux-only).