Refactor git change detection in bootstrap #138591

Kobzol · 2025-03-17T07:58:14Z

While working on #138395, I finally found the courage to delve into the insides of git path change detection in bootstrap, which is used (amongst other things) to detect if we should rebuilt od download [llvm|rustc|gcc]. I found it a bit hard to understand, and given that this code was historically quite fragile, I thought that it would be better to rebuild it from scratch.

The previous approach had a bunch of limitations:

It separated the computation of "are there local changes?" and "what upstream SHA should we use?" even though these two things are intertwined.
It used hacks to work around what happens on CI.
It had special cases for CI scattered throughout the codebase, rather than centralized in one place.
It wasn't documented enough and didn't have tests for the git behavior.

The current approach should hopefully resolve all of that. I implemented a single entrypoint called check_path_modifications (naming bikeshed pending, half of the time I spend on this PR was thinking about names, as it's quite tricky here..) that explicitly receives a mode of operation (in CI or outside CI), and accordingly figures out that upstream SHA that we should use for downloading artifacts and it also figures out if there are any local changes. Users of this function can then use this unified output to implement download-ci-X and other functionality. Notably, this change detection no longer uses git merge-base, which makes it easier to use and doesn't require setting up remotes.

I also added a bunch of integration tests that literally spawn a git repository on disk and then check that the function can deal with various situations (PR CI, auto/try CI, local builds).

After I built this inner layer, I used it for downloading GCC, LLVM and rustc. The latter two (and especially rustc) were using the last_modified_commit function before, but in all cases but one this function was actually only used to check if there are any local changes, which was IMO confusing. The LLVM handling would deserve a bit of refactoring, but that's a larger change that can be done as a follow-up.

I hope that the implementation is now clear and easy to understand, so that in combination with the tests we can have more confidence that it does what we want. I tried to include a lot of documentation in the code, so I won't be repeating the actual implementation details here, if there are any questions, I'll add the answers to the documentation too :)

The new approach explicitly supports three scenarios:

Running on PR CI, where we have one upstream bors parent commit and one PR merge commit made by GitHub.
Running on try/auto CI, where we have one upstream bors parent commit and one PR merge commit made by bors.
Running locally, where we assume that we have at least one upstream bors parent commit in our git history.

I removed the handling of upstreams on CI, as I think that it shouldn't be needed and I considered it to be a hack. However, it's possible that there are other use-cases that I haven't considered, so I want to ask around if people have other situations than the three use-cases described above. If there are other such use-cases, I would like to include them in the new centralized implementation and add them to the git test suite, rather than going back to the old ways :)

In particular, the code before relied on git merge-base, but I don't see why we can't just lookup the most recent bors commit and assume that is a merge commit that is also upstream? I might be running into Chesterton's Fence here :)

CC @pietroalbini To make sure that this won't break downstream users of Rust's CI.

Best reviewed commit by commit.

Companion PRs:

For testing beta: [do not merge] beta test for git change detection (#138591) #138597

r? @onur-ozkan

Fixes: #101907

try-job: x86_64-gnu-aux
try-job: aarch64-gnu
try-job: dist-x86_64-apple

rustbot · 2025-03-17T07:58:21Z

This PR changes how GCC is built. Consider updating src/bootstrap/download-ci-gcc-stamp.

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

This PR changes how LLVM is built. Consider updating src/bootstrap/download-ci-llvm-stamp.

Some changes occurred in src/tools/compiletest

cc @jieyouxu

This PR modifies src/bootstrap/src/core/config.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

pietroalbini · 2025-03-17T09:58:05Z

LGTM on the Ferrocene side. There is nothing here that would break our downstream usage.

On the Rust side, I recommend opening this PR against stable and beta too, and running a full bors try on it. We had issues in past releases where changes to this code would unexpectedly break stable or beta CI, and I'd love for those to be catched before merging.

Kobzol · 2025-03-17T10:01:46Z

Yes, I planned to do that, it's a good idea. Actually, I can try that right away.

[do not merge] beta test for git change detection (rust-lang#138591) Opening to test CI/bootstrap changes. r? `@ghost` try-job: x86_64-gnu-stable try-job: x86_64-gnu try-job: x86_64-gnu-llvm-19-1 try-job: dist-x86_64-linux

[do not merge] beta test for git change detection (rust-lang#138591) Opening to test CI/bootstrap changes from rust-lang#138591. r? `@ghost` try-job: x86_64-gnu-stable try-job: x86_64-gnu try-job: x86_64-gnu-llvm-19-1 try-job: dist-x86_64-linux

onur-ozkan · 2025-03-18T06:30:55Z

The changes look good, but I am not sure if they will break the if-unchanged tests and logic in the following cases:

PR that is supposed to use ci-rustc and ci-llvm
PR that is not supposed to use ci-rustc and ci-llvm
Testing the above cases on both stable and beta PRs

I think it's safer to make sure these won't be a problem before merging this.

[do not merge] beta test for git change detection (rust-lang#138591) Opening to test CI/bootstrap changes from rust-lang#138591. r? `@ghost` try-job: x86_64-gnu-aux

src/build_helper/src/git.rs

[do not merge] beta test for git change detection (rust-lang#138591) Opening to test CI/bootstrap changes from rust-lang#138591. r? `@ghost` try-job: x86_64-gnu-aux

Kobzol · 2025-03-18T11:02:31Z

@bors try

Refactor git change detection in bootstrap While working on rust-lang#138395, I finally found the courage to delve into the insides of git path change detection in bootstrap, which is used (amongst other things) to detect if we should rebuilt od download `[llvm|rustc|gcc]`. I found it a bit hard to understand, and given that this code was historically quite fragile, I thought that it would be better to rebuild it from scratch. The previous approach had a bunch of limitations: - It separated the computation of "are there local changes?" and "what upstream SHA should we use?" even though these two things are intertwined. - It used hacks to work around what happens on CI. - It had special cases for CI scattered throughout the codebase, rather than centralized in one place. - It wasn't documented enough and didn't have tests for the git behavior. The current approach should hopefully resolve all of that. I implemented a single entrypoint called `check_path_modifications` (naming bikeshed pending, half of the time I spend on this PR was thinking about names, as it's quite tricky here..) that explicitly receives a mode of operation (in CI or outside CI), and accordingly figures out that upstream SHA that we should use for downloading artifacts and it also figures out if there are any local changes. Users of this function can then use this unified output to implement `download-ci-X` and other functionality. I also added a bunch of integration tests that literally spawn a git repository on disk and then check that the function can deal with various situations (PR CI, auto/try CI, local builds). The tests are super fast and run in parallel, as they are currently in `build_helper` and not in `bootstrap`. After I built this inner layer, I used it for downloading GCC, LLVM and rustc. The latter two (and especially rustc) were using the `last_modified_commit` function before, but in all cases but one this function was actually only used to check if there are any local changes, which was IMO confusing. The LLVM handling would deserve a bit of refactoring, but that's a larger change that can be done as a follow-up. In the future we could cache the results of `check_path_modifications` to reduce the number of git invocations, but I don't think that it should be excessive even now. I hope that the implementation is now clear and easy to understand, so that in combination with the tests we can have more confidence that it does what we want. I tried to include a lot of documentation in the code, so I won't be repeating the actual implementation details here, if there are any questions, I'll add the answers to the documentation too :) The new approach explicitly supports three scenarios: - Running on PR CI, where we have one upstream bors parent commit and one PR merge commit made by GitHub. - Running on try/auto CI, where we have one upstream bors parent commit and one PR merge commit made by bors. - Running locally, where we assume that we have at least one upstream bors parent commit in our git history. I removed the handling of upstreams on CI, as I think that it shouldn't be needed and I considered it to be a hack. However, it's possible that there are other use-cases that I haven't considered, so I want to ask around if people have other situations than the three use-cases described above. If there are other such use-cases, I would like to include them in the new centralized implementation and add them to the git test suite, rather than going back to the old ways :) In particular, the code before relied on `git merge-base`, but I don't see why we can't just lookup the most recent bors commit and assume that is a merge commit that is also upstream? I might be running into Chesterton's Fence here :) CC `@pietroalbini` To make sure that this won't break downstream users of Rust's CI. Best reviewed commit by commit. Companion PRs: - For testing beta: rust-lang#138597 r? `@onur-ozkan` try-job: x86_64-gnu-aux

bors · 2025-03-18T11:03:44Z

⌛ Trying commit afe1f99 with merge 27ee8fc...

Kobzol · 2025-03-18T12:29:45Z

Did a bunch of follow-up clean-ups. Let me know if you want me to split this into multiple PRs! :)

src/bootstrap/src/utils/tests/git.rs

Kobzol · 2025-04-22T12:51:25Z

Hmm, weird, dist jobs definitely shouldn't try to use this logic to download anything...

@bors try

bors · 2025-04-22T12:52:34Z

⌛ Trying commit fbca453 with merge 45ecdb6...

Refactor git change detection in bootstrap While working on rust-lang#138395, I finally found the courage to delve into the insides of git path change detection in bootstrap, which is used (amongst other things) to detect if we should rebuilt od download `[llvm|rustc|gcc]`. I found it a bit hard to understand, and given that this code was historically quite fragile, I thought that it would be better to rebuild it from scratch. The previous approach had a bunch of limitations: - It separated the computation of "are there local changes?" and "what upstream SHA should we use?" even though these two things are intertwined. - It used hacks to work around what happens on CI. - It had special cases for CI scattered throughout the codebase, rather than centralized in one place. - It wasn't documented enough and didn't have tests for the git behavior. The current approach should hopefully resolve all of that. I implemented a single entrypoint called `check_path_modifications` (naming bikeshed pending, half of the time I spend on this PR was thinking about names, as it's quite tricky here..) that explicitly receives a mode of operation (in CI or outside CI), and accordingly figures out that upstream SHA that we should use for downloading artifacts and it also figures out if there are any local changes. Users of this function can then use this unified output to implement `download-ci-X` and other functionality. Notably, this change detection no longer uses `git merge-base`, which makes it easier to use and doesn't require setting up remotes. I also added a bunch of integration tests that literally spawn a git repository on disk and then check that the function can deal with various situations (PR CI, auto/try CI, local builds). After I built this inner layer, I used it for downloading GCC, LLVM and rustc. The latter two (and especially rustc) were using the `last_modified_commit` function before, but in all cases but one this function was actually only used to check if there are any local changes, which was IMO confusing. The LLVM handling would deserve a bit of refactoring, but that's a larger change that can be done as a follow-up. I hope that the implementation is now clear and easy to understand, so that in combination with the tests we can have more confidence that it does what we want. I tried to include a lot of documentation in the code, so I won't be repeating the actual implementation details here, if there are any questions, I'll add the answers to the documentation too :) The new approach explicitly supports three scenarios: - Running on PR CI, where we have one upstream bors parent commit and one PR merge commit made by GitHub. - Running on try/auto CI, where we have one upstream bors parent commit and one PR merge commit made by bors. - Running locally, where we assume that we have at least one upstream bors parent commit in our git history. I removed the handling of upstreams on CI, as I think that it shouldn't be needed and I considered it to be a hack. However, it's possible that there are other use-cases that I haven't considered, so I want to ask around if people have other situations than the three use-cases described above. If there are other such use-cases, I would like to include them in the new centralized implementation and add them to the git test suite, rather than going back to the old ways :) In particular, the code before relied on `git merge-base`, but I don't see why we can't just lookup the most recent bors commit and assume that is a merge commit that is also upstream? I might be running into Chesterton's Fence here :) CC `@pietroalbini` To make sure that this won't break downstream users of Rust's CI. Best reviewed commit by commit. Companion PRs: - For testing beta: rust-lang#138597 r? `@onur-ozkan` Fixes: rust-lang#101907 try-job: x86_64-gnu-aux try-job: aarch64-gnu try-job: dist-x86_64-apple

bors · 2025-04-22T15:09:29Z

☀️ Try build successful - checks-actions
Build commit: 45ecdb6 (45ecdb6e0c486363390bed44b1f43fb269eab8e7)

Kobzol · 2025-04-22T15:33:27Z

Hmm, looks like it might have been spurious.

@bors r=Mark-Simulacrum

bors · 2025-04-22T15:33:30Z

💡 This pull request was already approved, no need to approve it again.

There's another pull request that is currently being tested, blocking this pull request: Autodiff flags #139700

bors · 2025-04-22T15:33:31Z

📌 Commit fbca453 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

bors · 2025-04-23T03:10:07Z

⌛ Testing commit fbca453 with merge 645d0ad...

bors · 2025-04-23T06:32:10Z

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 645d0ad to master...

github-actions · 2025-04-23T06:34:22Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 1a5bf12 (parent) -> 645d0ad (this PR)

Test differences

Show 18 test diffs

Stage 0

core::builder::tests::ci_rustc_if_unchanged_do_not_invalidate_on_library_changes_outside_ci: [missing] -> pass (J0)
core::builder::tests::ci_rustc_if_unchanged_do_not_invalidate_on_tool_changes: [missing] -> pass (J0)
core::builder::tests::ci_rustc_if_unchanged_invalidate_on_compiler_changes: [missing] -> pass (J0)
core::builder::tests::ci_rustc_if_unchanged_invalidate_on_library_changes_in_ci: [missing] -> pass (J0)
core::builder::tests::ci_rustc_if_unchanged_logic: pass -> [missing] (J0)
core::config::tests::test_auto_ci_changed_in_pr: [missing] -> pass (J0)
core::config::tests::test_auto_ci_unchanged_anywhere_select_parent: [missing] -> pass (J0)
core::config::tests::test_local_changes_in_head_upstream: [missing] -> pass (J0)
core::config::tests::test_local_changes_in_previous_upstream: [missing] -> pass (J0)
core::config::tests::test_local_changes_negative_path: [missing] -> pass (J0)
core::config::tests::test_local_changes_subtree_that_used_bors: [missing] -> pass (J0)
core::config::tests::test_local_committed_modifications: [missing] -> pass (J0)
core::config::tests::test_local_committed_modifications_subdirectory: [missing] -> pass (J0)
core::config::tests::test_local_no_upstream_commit: [missing] -> pass (J0)
core::config::tests::test_local_no_upstream_commit_with_changes: [missing] -> pass (J0)
core::config::tests::test_local_uncommitted_modifications: [missing] -> pass (J0)
core::config::tests::test_pr_ci_changed_in_pr: [missing] -> pass (J0)
core::config::tests::test_pr_ci_unchanged_anywhere: [missing] -> pass (J0)

Job group index

J0: aarch64-apple, aarch64-gnu, i686-gnu-2, i686-gnu-nopt-2, i686-msvc-2, x86_64-apple-1, x86_64-gnu, x86_64-gnu-llvm-19-3, x86_64-gnu-llvm-20-3, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-2, x86_64-msvc-2

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 645d0ad2a4f145ae576e442ec5c73c0f8eed829b --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

x86_64-apple-2: 4944.5s -> 6482.6s (31.1%)
x86_64-apple-1: 8780.5s -> 10248.2s (16.7%)
dist-x86_64-linux: 5018.4s -> 5544.0s (10.5%)
dist-x86_64-apple: 10261.4s -> 11332.2s (10.4%)
dist-apple-various: 6420.2s -> 5786.1s (-9.9%)
dist-aarch64-apple: 4916.3s -> 5348.9s (8.8%)
aarch64-apple: 3971.4s -> 3639.4s (-8.4%)
x86_64-gnu-distcheck: 4570.8s -> 4859.2s (6.3%)
dist-aarch64-msvc: 8566.6s -> 9083.1s (6.0%)
dist-aarch64-linux: 5261.4s -> 5515.5s (4.8%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2025-04-23T08:03:11Z

Finished benchmarking commit (645d0ad): comparison URL.

Overall result: ❌ regressions - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

If the regression was expected or you think it can be justified,
please write a comment with sufficient written justification, and add
@rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
If you think that you know of a way to resolve the regression, try to create
a new PR with a fix for the regression.
If you do not understand the regression or you think that it is just noise,
you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.1%, 0.3%]	13
Regressions ❌ (secondary)	0.3%	[0.2%, 0.6%]	42
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.2%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.2%	[-0.2%, 0.3%]	14

Max RSS (memory usage)

Results (primary 2.0%, secondary 0.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.0%	[1.7%, 2.3%]	2
Regressions ❌ (secondary)	2.1%	[1.8%, 2.4%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.9%	[-7.7%, -4.1%]	2
All ❌✅ (primary)	2.0%	[1.7%, 2.3%]	2

Cycles

Results (secondary 0.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.8%	[2.8%, 2.8%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.5%	[-2.5%, -2.5%]	1
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 774.578s -> 776.892s (0.30%)
Artifact size: 365.08 MiB -> 365.04 MiB (-0.01%)

Kobzol · 2025-04-23T08:48:44Z

I checked the CI logs and didn't find anything suspicious. Eyeballing the historical charts of the regressed benchmarks, my only conclusion is that this has to be noise, as this PR shouldn't have affected dist builders nor the compiler in any way.

…git-config, r=jieyouxu Remove git repository from git config It is no longer needed after rust-lang#138591. We could even remove the `nightly_branch` field, but it still has one usage. r? `@jieyouxu`

nnethercote · 2025-04-24T12:35:23Z

When I run the bootstrap tests locally I get the failure new failures. Could this PR be responsible?

running 119 tests
........................................................................
core::config::tests::test_local_changes_subtree_that_used_bors ... F

core::config::tests::test_local_committed_modifications ... F
..............  88/119
...............................

failures:

---- core::config::tests::test_local_changes_subtree_that_used_bors stdout ----
Running cd "/tmp/.tmpQ834nG" && "git" "init"
Running cd "/tmp/.tmpQ834nG" && "git" "config" "user.name" "Tester"
Running cd "/tmp/.tmpQ834nG" && "git" "config" "user.email" "[email protected]"
Running cd "/tmp/.tmpQ834nG" && "git" "add" "."
Running cd "/tmp/.tmpQ834nG" && "git" "commit" "-m" "commit message"
Running cd "/tmp/.tmpQ834nG" && "git" "rev-parse" "HEAD"
Running cd "/tmp/.tmpQ834nG" && "git" "branch" "-m" "main"
Running cd "/tmp/.tmpQ834nG" && "git" "rev-parse" "--abbrev-ref" "HEAD"
Running cd "/tmp/.tmpQ834nG" && "git" "checkout" "-b" "previous-pr"
Running cd "/tmp/.tmpQ834nG" && "git" "add" "."
Running cd "/tmp/.tmpQ834nG" && "git" "commit" "-m" "commit message"
Running cd "/tmp/.tmpQ834nG" && "git" "rev-parse" "HEAD"
Running cd "/tmp/.tmpQ834nG" && "git" "switch" "main"
Running cd "/tmp/.tmpQ834nG" && "git" "merge" "--no-commit" "--no-ff" "previous-pr"
Running cd "/tmp/.tmpQ834nG" && "git" "rev-parse" "--abbrev-ref" "HEAD"
Running cd "/tmp/.tmpQ834nG" && "git" "commit" "-m" "Merge of previous-pr into main" "--author" "Merge bot <[email protected]>"
Running cd "/tmp/.tmpQ834nG" && "git" "branch" "-d" "previous-pr"
Running cd "/tmp/.tmpQ834nG" && "git" "rev-parse" "HEAD"
Running cd "/tmp/.tmpQ834nG" && "git" "switch" "--orphan" "subtree"
Running cd "/tmp/.tmpQ834nG" && "git" "add" "."
Running cd "/tmp/.tmpQ834nG" && "git" "commit" "-m" "commit message"
Running cd "/tmp/.tmpQ834nG" && "git" "rev-parse" "HEAD"
Running cd "/tmp/.tmpQ834nG" && "git" "rev-parse" "--abbrev-ref" "HEAD"
Running cd "/tmp/.tmpQ834nG" && "git" "checkout" "-b" "previous-pr"
Running cd "/tmp/.tmpQ834nG" && "git" "add" "."
Running cd "/tmp/.tmpQ834nG" && "git" "commit" "-m" "commit message"
Running cd "/tmp/.tmpQ834nG" && "git" "rev-parse" "HEAD"
Running cd "/tmp/.tmpQ834nG" && "git" "switch" "subtree"
Running cd "/tmp/.tmpQ834nG" && "git" "merge" "--no-commit" "--no-ff" "previous-pr"
Running cd "/tmp/.tmpQ834nG" && "git" "rev-parse" "--abbrev-ref" "HEAD"
Running cd "/tmp/.tmpQ834nG" && "git" "commit" "-m" "Merge of previous-pr into subtree" "--author" "Merge bot <[email protected]>"
Running cd "/tmp/.tmpQ834nG" && "git" "branch" "-d" "previous-pr"
Running cd "/tmp/.tmpQ834nG" && "git" "rev-parse" "HEAD"
Running cd "/tmp/.tmpQ834nG" && "git" "commit" "--amend" "--date" "Wed Feb 16 14:00 2011 +0100" "--no-edit"
Running cd "/tmp/.tmpQ834nG" && "git" "switch" "main"
Running cd "/tmp/.tmpQ834nG" && "git" "merge" "subtree" "--allow-unrelated"
Running cd "/tmp/.tmpQ834nG" && "git" "rev-parse" "--abbrev-ref" "HEAD"
Running cd "/tmp/.tmpQ834nG" && "git" "checkout" "-b" "previous-pr"
Running cd "/tmp/.tmpQ834nG" && "git" "add" "."
Running cd "/tmp/.tmpQ834nG" && "git" "commit" "-m" "commit message"

thread 'core::config::tests::test_local_changes_subtree_that_used_bors' panicked at src/bootstrap/src/utils/tests/git.rs:125:13:
Git command `cd "/tmp/.tmpQ834nG" && "git" "commit" "-m" "commit message"` failed
Stdout
On branch previous-pr
nothing to commit, working tree clean
Stderr


---- core::config::tests::test_local_committed_modifications stdout ----
Running cd "/tmp/.tmpHfIPXx" && "git" "init"
Running cd "/tmp/.tmpHfIPXx" && "git" "config" "user.name" "Tester"
Running cd "/tmp/.tmpHfIPXx" && "git" "config" "user.email" "[email protected]"
Running cd "/tmp/.tmpHfIPXx" && "git" "add" "."
Running cd "/tmp/.tmpHfIPXx" && "git" "commit" "-m" "commit message"
Running cd "/tmp/.tmpHfIPXx" && "git" "rev-parse" "HEAD"
Running cd "/tmp/.tmpHfIPXx" && "git" "branch" "-m" "main"
Running cd "/tmp/.tmpHfIPXx" && "git" "rev-parse" "--abbrev-ref" "HEAD"
Running cd "/tmp/.tmpHfIPXx" && "git" "checkout" "-b" "previous-pr"
Running cd "/tmp/.tmpHfIPXx" && "git" "add" "."
Running cd "/tmp/.tmpHfIPXx" && "git" "commit" "-m" "commit message"
Running cd "/tmp/.tmpHfIPXx" && "git" "rev-parse" "HEAD"
Running cd "/tmp/.tmpHfIPXx" && "git" "switch" "main"
Running cd "/tmp/.tmpHfIPXx" && "git" "merge" "--no-commit" "--no-ff" "previous-pr"
Running cd "/tmp/.tmpHfIPXx" && "git" "rev-parse" "--abbrev-ref" "HEAD"
Running cd "/tmp/.tmpHfIPXx" && "git" "commit" "-m" "Merge of previous-pr into main" "--author" "Merge bot <[email protected]>"
Running cd "/tmp/.tmpHfIPXx" && "git" "branch" "-d" "previous-pr"
Running cd "/tmp/.tmpHfIPXx" && "git" "rev-parse" "HEAD"
Running cd "/tmp/.tmpHfIPXx" && "git" "rev-parse" "--abbrev-ref" "HEAD"
Running cd "/tmp/.tmpHfIPXx" && "git" "checkout" "-b" "previous-pr"
Running cd "/tmp/.tmpHfIPXx" && "git" "add" "."
Running cd "/tmp/.tmpHfIPXx" && "git" "commit" "-m" "commit message"
Running cd "/tmp/.tmpHfIPXx" && "git" "rev-parse" "HEAD"
Running cd "/tmp/.tmpHfIPXx" && "git" "switch" "main"
Running cd "/tmp/.tmpHfIPXx" && "git" "merge" "--no-commit" "--no-ff" "previous-pr"
Running cd "/tmp/.tmpHfIPXx" && "git" "rev-parse" "--abbrev-ref" "HEAD"
Running cd "/tmp/.tmpHfIPXx" && "git" "commit" "-m" "Merge of previous-pr into main" "--author" "Merge bot <[email protected]>"
Running cd "/tmp/.tmpHfIPXx" && "git" "branch" "-d" "previous-pr"
Running cd "/tmp/.tmpHfIPXx" && "git" "rev-parse" "HEAD"
Running cd "/tmp/.tmpHfIPXx" && "git" "checkout" "-b" "feature"
Running cd "/tmp/.tmpHfIPXx" && "git" "add" "."
Running cd "/tmp/.tmpHfIPXx" && "git" "commit" "-m" "commit message"

thread 'core::config::tests::test_local_committed_modifications' panicked at src/bootstrap/src/utils/tests/git.rs:125:13:
Git command `cd "/tmp/.tmpHfIPXx" && "git" "commit" "-m" "commit message"` failed
Stdout
On branch feature
nothing to commit, working tree clean
Stderr



failures:
    core::config::tests::test_local_changes_subtree_that_used_bors
    core::config::tests::test_local_committed_modifications

Kobzol · 2025-04-24T13:30:20Z

Yes, that is definitely caused by this PR, because it introduced the test. I can't seem to reproduce it locally though. Does it fail always or only sometimes?

…git-config, r=jieyouxu Remove git repository from git config It is no longer needed after rust-lang#138591. We could even remove the `nightly_branch` field, but it still has one usage. r? ``@jieyouxu``

nnethercote · 2025-04-24T21:33:38Z

It always fails: with a clean tree, with uncommitted changes, or with committed changes.

Rollup merge of rust-lang#140191 - Kobzol:remove-git-repository-from-git-config, r=jieyouxu Remove git repository from git config It is no longer needed after rust-lang#138591. We could even remove the `nightly_branch` field, but it still has one usage. r? ``@jieyouxu``

…g, r=jieyouxu Remove git repository from git config It is no longer needed after rust-lang/rust#138591. We could even remove the `nightly_branch` field, but it still has one usage. r? ``@jieyouxu``

Kobzol · 2025-04-25T07:03:44Z

Just to clarify, the test runs git commands in a temporary directory, so it shouldn't be affected in any way by the git state of your actual rustc checkout (otherwise it would be very brittle, of course). The test fails when it tries to do git commit, but the working area is clean. That is weird, because right before that we essentially do echo "line" >> x && git add .. I wonder if git add . doesn't add everything to the index? Does git add . work like that for you? What git version and OS do you have?

nnethercote · 2025-04-25T21:20:24Z

I'm using git 2.45.2 on Ubuntu 24.10.

rustbot assigned onur-ozkan Mar 17, 2025

rustbot added the T-release Relevant to the release subteam, which will review and decide on the PR/issue. label Mar 17, 2025

Kobzol force-pushed the git-ci branch from 4b7c63b to 0f258ca Compare March 17, 2025 09:45

Kobzol mentioned this pull request Mar 17, 2025

[do not merge] beta test for git change detection (#138591) #138597

Closed

jieyouxu self-assigned this Mar 17, 2025

jieyouxu removed their assignment Mar 18, 2025

Kobzol commented Mar 18, 2025

View reviewed changes

src/build_helper/src/git.rs Outdated Show resolved Hide resolved

Kobzol force-pushed the git-ci branch from 0f258ca to afe1f99 Compare March 18, 2025 09:58

Kobzol force-pushed the git-ci branch from afe1f99 to 1fc0921 Compare March 18, 2025 12:29

Kobzol force-pushed the git-ci branch 2 times, most recently from 63be8ba to e1fe7f2 Compare March 19, 2025 10:07

onur-ozkan reviewed Mar 19, 2025

View reviewed changes

src/bootstrap/src/utils/tests/git.rs Show resolved Hide resolved

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 22, 2025

bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 23, 2025

bors merged commit 645d0ad into rust-lang:master Apr 23, 2025
7 checks passed

rustbot added this to the 1.88.0 milestone Apr 23, 2025

Kobzol deleted the git-ci branch April 23, 2025 06:59

Kobzol mentioned this pull request Apr 23, 2025

Remove git repository from git config #140191

Merged

bors mentioned this pull request Apr 23, 2025

DRAFT: Add an aarch64-msvc build running on ARM64 Windows #140136

Draft

rustbot added the perf-regression Performance regression. label Apr 23, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Refactor git change detection in bootstrap #138591

Refactor git change detection in bootstrap #138591

Kobzol commented Mar 17, 2025 •

edited

Loading

rustbot commented Mar 17, 2025

pietroalbini commented Mar 17, 2025

Kobzol commented Mar 17, 2025

onur-ozkan commented Mar 18, 2025

Kobzol commented Mar 18, 2025

bors commented Mar 18, 2025

Kobzol commented Mar 18, 2025

Kobzol commented Apr 22, 2025

bors commented Apr 22, 2025

bors commented Apr 22, 2025

Kobzol commented Apr 22, 2025

bors commented Apr 22, 2025

bors commented Apr 22, 2025

bors commented Apr 23, 2025

bors commented Apr 23, 2025

github-actions bot commented Apr 23, 2025

Stage 0

rust-timer commented Apr 23, 2025

Kobzol commented Apr 23, 2025

nnethercote commented Apr 24, 2025

Kobzol commented Apr 24, 2025

nnethercote commented Apr 24, 2025

Kobzol commented Apr 25, 2025

nnethercote commented Apr 25, 2025

Refactor git change detection in bootstrap #138591

Refactor git change detection in bootstrap #138591

Conversation

Kobzol commented Mar 17, 2025 • edited Loading

rustbot commented Mar 17, 2025

pietroalbini commented Mar 17, 2025

Kobzol commented Mar 17, 2025

onur-ozkan commented Mar 18, 2025

Kobzol commented Mar 18, 2025

bors commented Mar 18, 2025

Kobzol commented Mar 18, 2025

Kobzol commented Apr 22, 2025

bors commented Apr 22, 2025

bors commented Apr 22, 2025

Kobzol commented Apr 22, 2025

bors commented Apr 22, 2025

bors commented Apr 22, 2025

bors commented Apr 23, 2025

bors commented Apr 23, 2025

github-actions bot commented Apr 23, 2025

Test differences

Stage 0

Job duration changes

rust-timer commented Apr 23, 2025

Overall result: ❌ regressions - please read the text below

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Kobzol commented Apr 23, 2025

nnethercote commented Apr 24, 2025

Kobzol commented Apr 24, 2025

nnethercote commented Apr 24, 2025

Kobzol commented Apr 25, 2025

nnethercote commented Apr 25, 2025

Kobzol commented Mar 17, 2025 •

edited

Loading