Skip to content
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

Files changed doesn't properly reflect changes against non base branch #6479

Closed
JohnRDOrazio opened this issue Nov 15, 2024 · 3 comments
Closed
Assignees

Comments

@JohnRDOrazio
Copy link

JohnRDOrazio commented Nov 15, 2024

Creating a new issue seeing that #5545 was closed, but is not resolved.

I have a main branch with the stable, production ready code, which reflects the latest published release.

I have a development branch where all of the latest PR's for features and non-security bugfixes are merged.

When I create a new PR from VSCode against the development branch, the files changed is showing files changed in comparison to the main branch, not the development branch. Which makes it look scary, and prevents me from continuing to create the PR from VSCode.

See #5545 (comment) :

Image

All those deleted files were already removed / refactored in the development branch. They shouldn't be showing in a PR against the development branch.

@JohnRDOrazio
Copy link
Author

JohnRDOrazio commented Nov 16, 2024

I found a workaround for now, if I switch the base to main, then switch the base back to development, the Files changed then show correctly. They just weren't picked up right away, as they should be (since the base was automatically detected as development).

@JohnRDOrazio
Copy link
Author

Another thing I noticed, is that after Merging the PR and deleting both local and remote branches, I am automatically brought back to the main branch instead of the development branch. Perhaps it would make more sense to checkout the base branch for the merge (in this case, development) rather than the main branch? That way the user / developer is brought back to where he started from when the feature branch was first created.

@alexr00 alexr00 self-assigned this Dec 2, 2024
@alexr00 alexr00 added this to the January 2025 milestone Dec 2, 2024
@alexr00
Copy link
Member

alexr00 commented Dec 18, 2024

I just pushed a new fix for #5545, which should also fix this issue.

Checking out the target branch instead of the default branch is a duplicate of #4582

@alexr00 alexr00 closed this as completed Dec 18, 2024
@alexr00 alexr00 removed this from the January 2025 milestone Dec 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants