-
Notifications
You must be signed in to change notification settings - Fork 22.5k
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
fix(css): Fix flex: 1
explanation
#37553
Conversation
files/en-us/web/css/css_flexible_box_layout/basic_concepts_of_flexbox/index.md
Outdated
Show resolved
Hide resolved
…flexbox/index.md Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Preview URLs Flaws (48)URL:
(comment last updated: 2025-01-14 01:41:46) |
Could you rebase these 3 commits into 1? |
Why? The |
Because it's almost always better to simplify as early as possible in any pipeline.
I noticed, but the
Do you know that, or are you assuming that? I am not familiar enough with this particular pipeline to know if that's the case or not, but getting into the habit of squashing properly is certainly advised, as that is always a great initiative regardless of pipeline, and it helps you be better organized, too. Just because some tools compensate for infelicities, does not necessarily mean you should not solve problems at the source before they potentially create more problems. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@OnkarRuikar sounds basically good to me. I think the "items start" change is needed for consistency, but I also suggested a new bit to clarify what you mean. What do you think?
I don't feel that strongly about it; Approving.
files/en-us/web/css/css_flexible_box_layout/basic_concepts_of_flexbox/index.md
Outdated
Show resolved
Hide resolved
…flexbox/index.md Co-authored-by: Chris Mills <chrisdavidmills@gmail.com>
@Hexstream: quite the contrary. You will find many open source projects (at least, many that I work on) strongly advise against single-commit PRs.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perfect, thanks @OnkarRuikar!
@Josh-Cena Thank you, interesting perspective!
Well, that's what I said, "One commit per semantic change"... I still think all commits here really represented one semantic change, an atomic piece of work...
Obviously, although a new feature and its tests should preferably go in the same commit, I think.
Right, I guess a possible workaround would be to advise people to comment when they force-push... It would be nice if GitHub would just add better support for this...
Actually, there is a "Compare" feature for seeing the diff between before and after a force-push, isn't it? Anyway, even based on all this, I still strongly prefer rebased commits for my own projects, but nice to know that may not be the best policy for all projects... |
Basic concepts of flexbox
page #37475 (comment)The current statement is correct if you directly see the end result. However, as the sentence uses
flex-basis: 0
, we need to be more specific about what actually happens behind the scenes.