-
Notifications
You must be signed in to change notification settings - Fork 13.5k
tests/ui
: A New Order [15/N]
#143118
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
tests/ui
: A New Order [15/N]
#143118
Conversation
|
Could you please move/rename files in a separate commit from any other updates? Otherwise the git blame+history gets completely wiped out :( |
Hm, honestly this is the first time I’m hearing about this, we should probably discuss it Because I’m working off the guidelines I was given by @jieyouxu (important addition 1: they weren’t exactly official guidelines, more like suggestions on how to make my PRs easier to review) (important addition 2 following up on addition 1: since I’m someone who cares a lot about making reviews easier, I make it a priority to follow that suggestions) I remember that in some of very first my PRs I was told to keep changes for each test in its own dedicated commit |
If the changes are "small" then it can be okay, e.g. a612e73 has a rename and some updates and it's okay. But for anything "big" where much of the file is getting touched, renaming needs to be separate from the changes. E.g. 3597677 it thinks you deleted a file and added an unrelated one, so history looks like this https://github.com/rust-lang/rust/commits/3597677049ee5da6c48e63f9ee4279fe7f85e3f2/tests/ui/derives/derive-Debug-enum-variants.rs. Compare this to the history for that file in "small" vs. "big" is tough to quantify since it depends on git's similarity index, so it is advisable to play it safe and always rename files in a separate commit. (Not just for this PR series, it's always a git thing.) Fwiw I did mention this at https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Discussion.20for.20ui.20test.20suite.20improvements/near/523696309, no worries if you don't check Zulip too often |
Oh, you've mentioned it about like a month ago, I really didn't use Zullip that much, most of the time I even forget it exist honestly And It's pretty relatively late because I already made about 15 PRs, but, I can start use this rule from next PR if this suits to you (I also do want to care about history, really didn't knew about this before) because rebasing this now will be a tough task In this PR I putted links to related PRs or issues if there were interesting ones So yeah, sorry again 😅 I Don't use zullip at all, but seems like it's time to start to |
No worries at all! Git can be subtle sometimes, better late than never 😆
Not sure how familiar you are with git, but it should let you do this reasonably elegantly if you are up for trying: # Start a rebase
git rebase -i master --keep-base
b # add this line so you get a chance to add a commit
pick a612e7349d4 moved renamed docs formatted | lexical-scoping.rs
pick 3ca5b1a7b04 moved renamed docs formatted | link-section.rs
pick cbbc9d4eb82 deleted | log-err-phi.rs
pick 3597677049e moved renamed docs formatted | log-knows-the-names-of-variants.rs
pick f35f79be665 moved renamed docs formatted | logging-only-prints-once.rs
pick cc044b603f1 moved renamed docs | loud_ui.rs
pick 4e43f317868 moved renamed docs | max-min-classes.rs
# save + exit
# For convenience, print the diff so you see which files changed in which commits
git log --oneline --stat $(git merge-base tf15 master)..tf15
# Make a commit with just the renames
# You don't _have_ to do all of them here, but at least the ones that conflict
git mv tests/ui/lexical-scoping.rs tests/ui/resolve/type-param-local-var-shadowing.rs
git mv tests/ui/link-section.rs tests/ui/linkage-attr/link-section-placement.rs
# ...
git commit -m "Move some UI tests to more applicable directories"
# Continue
git rebase --continue
# Now most _should_ just work. But each time it stops, just do:
git add path/to/file/after/rename/for/this/commit
git rebase --continue
# Make sure everything looks the same...
git diff origin/tf15
# ... and update!
git push --force-with-lease
git branch -d tmp-rename |
I'm definitely up to trying but little bit later today since it's a deep night for me at the moment (5 am) Also if you have r+ rights you can review this and next PRs if you have vibe to, because jieyouxu is not mentoring this project at the moment and said
So I'm looking for someone until jieyouxu return (Also, I would rate my git skills on 4-5/10) |
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.
Lgtm with the history fix then. Feel free to just squash the edits if that's what you usually do, as long as the move is still a separate commit.
If Jieyou isn't able to review these for a little while then you probably don't need to r?
anyone in particular, any reviewer that gets assigned should be able to okay them.
Yeah, I saw this edit after this PR This will be a tricky but I will try it today and ping you after Hm, also wondering about squashing commits If I had two commits (if i get you right this is how better keep commits to save git blame) And then before merge I squash this commits into one How will git handle this and will it consider the file deleted? |
Sgtm 👍 just fyi, when files move you do need to pass
If you mean squashing those two commits (edit+move together), no don't do that. It's fine to have >1 commit in a PR if it makes sense, we just don't want a bunch of super tiny commits that don't really have any reason to be separated.
Please feel free to come back to this tomorrow, I don't mean to keep you up 😆 |
FWIW I don't mind specifically how the commits are organized that much, if splitting into {plain move, edits} commits make git history better then great. Since you're looking at it already |
@tgross35 I gave a try and it's harder than it's looks like, it's better to try this from next PRs, this hacks with adding But, I still have one unclosed important question to this
And I need @jieyouxu to discuss it, because, it means we will have about 12-18 commits in each PR, which personally for me not sounds good |
No, I believe Trevor specifically means two commits {move-only, edits}, which is >1 commits, not 12 commits. It's the separate move commit that helps with git history. |
Hm, so you mean something like: Imagine we have tests In first commit I do
Then in separate commits I do
Right? |
Here's draft of next PR, it still shows some files like deleted even tho I made moves in separate commit? https://github.com/rust-lang/rust/compare/master...Kivooeo:tf16?expand=1 |
The overall diff will still show as deleted and re-added, that part is okay. You need to look at the history for a specific file; e.g. https://github.com/rust-lang/rust/commits/db989fc3ce6e618f4f835ac9e8f8f52cbb2ecbd8/tests/ui/codegen/maximal-hir-to-mir-coverage-flag.rs, notice how it has "Renamed from tests/ui/maximal_mir_to_hir_coverage.rs" at the bottom. That's all correct!
If you are having rebase problems, I'm happy to do the fix and push your branch - just ask :) but where did you get stuck? Purely for the mental model, don't worry if it doesn't make much too much sense, but this is basically what happens when you do a rebase:
^ looking at |
(I will read the explanation after I send this message so I'm just trying to explain what goes wrong when I tried to make it)
I stucked on a very first step
It started rebasing 5 thousand files I thought I was a mistake and did instead
Which worked better then it open me a this windows you showed in guide (with commits and pick word, I don't really know how this windows called, I guess rebase editor maybe?) I added a just And it moved head on commit that was before my first commit, which is correct as far as I understand... But then I don’t know how to rewrite the history so that the file move ends up in a single initial commit, keeping only the content changes in the subsequent commits (hopefully I explained this part clealy because my english is not that good) Also I’m little confused about adding |
I'm doing But this one sounds more complex than such small fixes, if for a person who knows git well it might be an easy task, but for me it's more like a stressfull adventure in dark forest 😅 |
For any git thing there are 1000 ways to get the same results 😆 I'm happy to help you get there, but I'm also happy to do it for you because I know this kind of thing is tricky and we certainly don't expect all contributors to know git like the back of their hand.
Yeah you want the same results as So maybe you need to replace
All sounds correct!
Once you're at this point, you want to create a new commit that never existed before, which just moves all the files. You can do anything at a So do (as a note, it might make things slightly easier if you squash before doing this since there will be a single conflict commit then, and you can
Never apologize, it's quite alright :)
|
The reason I'd think that this And yeah, also if you could just push this changes in this branch it will make all easier and I could continue working on it with an easy heart doing separate commit with plain moves from start |
Prepare for rework done in the rest of [PR143118]. [PR143118]: https://www.github.com/rust-lang/rust/pull/143118 Co-authored-by: Kivooeo <Kivooeo123@gmail.com>
Pushed! Basically exactly #143118 (comment) for reference. (I'll help with the rest tomorrow, going offline for the day) |
Thanks! |
Mind squashing the rest? The actual changes lgtm #143118 (review), I just didn't want to lose the history |
Sure I squash commits that don't move anything |
Also I should clarify one thing, you made moves in first commit so I can safely squash rest of them? So we will have just two commits, first with moves you made and second commit with changes (and moves that dont recognize by git as deleted file) (asking to be giga very super sure because unsquashing will not be most fun task) |
Since our working hours are so different, I think the best solution to this situation is this: If possible and if you have free time and vibe to review it (because it's not most fun task to do), you do a review to PRs and if everything is fine or needs to be fixed, you write about it and delegate the approval rights to me. Then, in my free time, I look and fix if there is anything and then squash commits and then approve it myself In my opinion this is very smooth workflow, something like this were done here #142429 (comment) successfully Also I'd love to hear your rate of ten to this solution |
Yes, squashing everything except the first commit together is good :) |
@rustbot ready |
Thanks! |
Rollup of 14 pull requests Successful merges: - #142429 (`tests/ui`: A New Order [13/N]) - #142514 (Miri: handling of SNaN inputs in `f*::pow` operations) - #143066 (Use let chains in the new solver) - #143090 (Workaround for memory unsafety in third party DLLs) - #143118 (`tests/ui`: A New Order [15/N]) - #143159 (Do not freshen `ReError`) - #143168 (`tests/ui`: A New Order [16/N]) - #143176 (fix typos and improve clarity in documentation) - #143187 (Add my work email to mailmap) - #143190 (Use the `new` method for `BasicBlockData` and `Statement`) - #143195 (`tests/ui`: A New Order [17/N]) - #143196 (Port #[link_section] to the new attribute parsing infrastructure) - #143199 (Re-disable `tests/run-make/short-ice` on Windows MSVC again) - #143219 (Show auto trait and blanket impls for `!`) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of #143118 - Kivooeo:tf15, r=tgross35 `tests/ui`: A New Order [15/N] > [!NOTE] > > Intermediate commits are intended to help review, but will be squashed prior to merge. Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of #133895. r? `@jieyouxu`
Rollup of 14 pull requests Successful merges: - rust-lang/rust#142429 (`tests/ui`: A New Order [13/N]) - rust-lang/rust#142514 (Miri: handling of SNaN inputs in `f*::pow` operations) - rust-lang/rust#143066 (Use let chains in the new solver) - rust-lang/rust#143090 (Workaround for memory unsafety in third party DLLs) - rust-lang/rust#143118 (`tests/ui`: A New Order [15/N]) - rust-lang/rust#143159 (Do not freshen `ReError`) - rust-lang/rust#143168 (`tests/ui`: A New Order [16/N]) - rust-lang/rust#143176 (fix typos and improve clarity in documentation) - rust-lang/rust#143187 (Add my work email to mailmap) - rust-lang/rust#143190 (Use the `new` method for `BasicBlockData` and `Statement`) - rust-lang/rust#143195 (`tests/ui`: A New Order [17/N]) - rust-lang/rust#143196 (Port #[link_section] to the new attribute parsing infrastructure) - rust-lang/rust#143199 (Re-disable `tests/run-make/short-ice` on Windows MSVC again) - rust-lang/rust#143219 (Show auto trait and blanket impls for `!`) r? `@ghost` `@rustbot` modify labels: rollup
Note
Intermediate commits are intended to help review, but will be squashed prior to merge.
Some
tests/ui/
housekeeping, to trim down number of tests directly undertests/ui/
. Part of #133895.r? @jieyouxu