-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 checking git submodules during a commit hook #126255
Conversation
Failed to set assignee to
|
This PR modifies If appropriate, please update |
r? @onur-ozkan |
This comment has been minimized.
This comment has been minimized.
Hm... Any idea why that command would fail...?
|
To reproduce the problem, you can enter the container in interactive mode with Running the failed command from #126255 (comment) gives the following error message: nimda@b536d58a7363:~$ git --git-dir /checkout/.git rev-list --author=bors@rust-lang.org -n1 --first-parent HEAD -- /checkout/src/llvm-project /checkout/src/bootstrap/download-ci-llvm-stamp /checkout/src/version
fatal: /checkout/src/llvm-project: '/checkout/src/llvm-project' is outside repository at '/checkout/obj' As far as I understand you cannot access another repository (or submodule) while explicitly setting |
That can't be quite right, |
fwiw changing current directory to |
I don't understand why changing the current directory makes a difference when |
I am definitely not understanding
and depending on my working directory, this sometimes shows a commit and sometimes not. And when my working dir is a different git checkout it just fails. So do we have to do both, change the working dir and set |
Ah, this explains it, partially. So we definitely need the working dir, or set But then also setting |
This could be the best solution. Adding |
I found something that works, but it still behaves a bit strange -- when I actually have an intended submodule change and Maybe we should just skip all submodule processing when GIT_DIR is set? That happens during a git invocation and doing advanced git surgery in the middle of that might just not be a good idea. |
9fe297e
to
f768fc8
Compare
Would setting |
I think you already did that before the latest change, right? The main issue was that we are manually constructing git commands all over the bootstrap codebase (which makes it hard to ensure setting |
I tried that, yeah -- but it's still not great in a commit hook: when you want to actually change the submodule, and then commit, weird stuff happens. It first un-does your change and then un-does the un-doing, at least with the cargo subrepo which is currently checked twice each time (first by the loop that always initializes cargo, then by the "check all existing submodules" check). |
Also to be clear I have not systematically searched for git invocations in the codebase, I just refactored the one I stumbled into. |
Due to rust-lang#125954, we had to modify git invocations with certain flags in rust-lang#126255. However, because there are so many instances of `Command::new("git")` in bootstrap, it is difficult to apply these solutions to all of them. This PR creates a helper function that unifies the git usage in bootstrap. Meaning, whenever special flags or hacks are needed, we can apply them to this single function which makes things much simpler for the bootstrap team. Signed-off-by: onur-ozkan <work@onurozkan.dev>
Can we wait until we ship #126309 ? It should help significantly in making this work cleaner. |
Due to rust-lang#125954, we had to modify git invocations with certain flags in rust-lang#126255. However, because there are so many instances of `Command::new("git")` in bootstrap, it is difficult to apply these solutions to all of them. This PR creates a helper function that unifies the git usage in bootstrap. Meaning, whenever special flags or hacks are needed, we can apply them to this single function which makes things much simpler for the bootstrap team. Signed-off-by: onur-ozkan <work@onurozkan.dev>
Due to rust-lang#125954, we had to modify git invocations with certain flags in rust-lang#126255. However, because there are so many instances of `Command::new("git")` in bootstrap, it is difficult to apply these solutions to all of them. This PR creates a helper function that unifies the git usage in bootstrap. Meaning, whenever special flags or hacks are needed, we can apply them to this single function which makes things much simpler for the bootstrap team. Signed-off-by: onur-ozkan <work@onurozkan.dev>
Sure, this is not urgent. |
…r=Kobzol unify git command preperation Due to rust-lang#125954, we had to modify git invocations with certain flags in rust-lang#126255. However, because there are so many instances of `Command::new("git")` in bootstrap, it is difficult to apply these solutions to all of them. This PR creates a helper function that unifies the git usage in bootstrap. Meaning, whenever special flags or hacks are needed, we can apply them to this single function which makes things much simpler for the bootstrap team.
Rollup merge of rust-lang#126309 - onur-ozkan:unify-git-utilization, r=Kobzol unify git command preperation Due to rust-lang#125954, we had to modify git invocations with certain flags in rust-lang#126255. However, because there are so many instances of `Command::new("git")` in bootstrap, it is difficult to apply these solutions to all of them. This PR creates a helper function that unifies the git usage in bootstrap. Meaning, whenever special flags or hacks are needed, we can apply them to this single function which makes things much simpler for the bootstrap team.
☔ The latest upstream changes (presumably #126540) made this pull request unmergeable. Please resolve the merge conflicts. |
It is merged. |
So which option would you prefer -- unsetting GIT_DIR and GIT_INDEX_FILE, or disabling the submodule handling entirely when they are set? |
We had this workaround previously, so if we unset GIT_DIR in bootstrap (in the centrealized git function in helper module), that should fix the problem. I am not sure why that undoing->un-undoing thing happens, but it doesn't break anything in the process as far as I understand.. |
Un-setting GIT_DIR is not enough, I tried that. One has to also unset GIT_INDEX_FILE.
I think it would break something for submodules that are only updated once, i.e. all the ones which are not forcefully checked out. (Ideally bootstrap would be patched to not update anything twice...) |
f768fc8
to
91c9f03
Compare
PR updated. @rustbot ready |
let checked_out_hash = | ||
output(helpers::git(Some(&absolute_path)).args(["rev-parse", "HEAD"])); | ||
// update_submodules | ||
let submodule_git = || helpers::git(Some(&absolute_path)); |
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.
I left this closure in since I think it makes the code more readable to abstract this common call away.
91c9f03
to
e3e7140
Compare
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.
Thanks for the fix!
Ideally bootstrap would be patched to not update anything twice...
We are planning to track and cache git certain invocations, I think by using the same interface we can achieve this.
@bors r+ rollup |
For this particular case, it seems easier to make |
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#126255 (fix checking git submodules during a commit hook) - rust-lang#126355 (Pass target to some run-make tests) - rust-lang#126567 (Rename `InstanceDef` -> `InstanceKind`) - rust-lang#126579 (Fix broken documentation link) - rust-lang#126596 (Add tracking issue number to async_drop APIs) - rust-lang#126603 (Update books) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#126255 - RalfJung:bootstrap-submodules, r=onur-ozkan fix checking git submodules during a commit hook Fixes rust-lang#125954 The one thing that still puzzles me is why this only is a problem with worktrees. r? `@onur`
Fixes #125954
The one thing that still puzzles me is why this only is a problem with worktrees.
r? @onur