-
Notifications
You must be signed in to change notification settings - Fork 13.3k
build_helper::git uses the upstream/master branch to tell if a file has been modified, but this branch is never automatically updated. #129528
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
this could be addressed by checking the timestamp on .git/refs/remotes/upstream/master and warning if it is very old |
@rustbot claim |
I ran into a similar issue where |
@RickRum should be pretty easy, just call the same warning method for both build steps maybe it should be used for all build steps? |
… r=albertlarsan68 warn the user if the upstream master branch is old fixes rust-lang#129528
… r=albertlarsan68 warn the user if the upstream master branch is old fixes rust-lang#129528
Rollup merge of rust-lang#129584 - lolbinarycat:old-upstream-warning, r=albertlarsan68 warn the user if the upstream master branch is old fixes rust-lang#129528
…larsan68 warn the user if the upstream master branch is old fixes rust-lang/rust#129528
force "HEAD" for non-CI and `git_upstream_merge_base` for CI environment When rust-lang/rust is configured as remote, some of the git logic (for tracking changed files) that uses get_closest_merge_commit starts to produce annoying results as the upstream branch becomes outdated quickly (since it isn't updated with git pull). We can rely on HEAD for non-CI environments as we specifically treat bors commits as merge commits, which also exist on upstream. As for CI environments, we should use `git_upstream_merge_base` to correctly track modified files as bors commits may be in `HEAD` but not yet on the upstream remote. This is also an alternative fix for rust-lang#129528 since rust-lang#131331 reverts the previous fix attempts.
force "HEAD" for non-CI and `git_upstream_merge_base` for CI environment When rust-lang/rust is configured as remote, some of the git logic (for tracking changed files) that uses get_closest_merge_commit starts to produce annoying results as the upstream branch becomes outdated quickly (since it isn't updated with git pull). We can rely on HEAD for non-CI environments as we specifically treat bors commits as merge commits, which also exist on upstream. As for CI environments, we should use `git_upstream_merge_base` to correctly track modified files as bors commits may be in `HEAD` but not yet on the upstream remote. This is also an alternative fix for rust-lang#129528 since rust-lang#131331 reverts the previous fix attempts.
Rollup merge of rust-lang#131358 - onur-ozkan:129528, r=Mark-Simulacrum force "HEAD" for non-CI and `git_upstream_merge_base` for CI environment When rust-lang/rust is configured as remote, some of the git logic (for tracking changed files) that uses get_closest_merge_commit starts to produce annoying results as the upstream branch becomes outdated quickly (since it isn't updated with git pull). We can rely on HEAD for non-CI environments as we specifically treat bors commits as merge commits, which also exist on upstream. As for CI environments, we should use `git_upstream_merge_base` to correctly track modified files as bors commits may be in `HEAD` but not yet on the upstream remote. This is also an alternative fix for rust-lang#129528 since rust-lang#131331 reverts the previous fix attempts.
force "HEAD" for non-CI and `git_upstream_merge_base` for CI environment When rust-lang/rust is configured as remote, some of the git logic (for tracking changed files) that uses get_closest_merge_commit starts to produce annoying results as the upstream branch becomes outdated quickly (since it isn't updated with git pull). We can rely on HEAD for non-CI environments as we specifically treat bors commits as merge commits, which also exist on upstream. As for CI environments, we should use `git_upstream_merge_base` to correctly track modified files as bors commits may be in `HEAD` but not yet on the upstream remote. This is also an alternative fix for rust-lang/rust#129528 since rust-lang/rust#131331 reverts the previous fix attempts.
I have my master branch set up to track the master branch of my fork (mainly because i don't want to accidentally pull in every git tag into my shallow clone), so
upstream/master
doesn't updated when i rungit pull
(presumably theupstream
remote was created by./x setup
? i don't remember creating it, and lots of code needs it (or another branch pointing to this repo) to work).as it turns out,
./x fmt
uses the state ofupstream/master
to determine if a file has been modified. so instead of it formatting every file that i modified, it formats every file anyone has modified in the last few months.at no point did anything warn me that i need to be updating a remote i didn't add. it should probably do that.
The text was updated successfully, but these errors were encountered: