[Note]
For folks browsing the repository and finding this PR: I've not yet merged this PR, as I haven't yet decided when and how to launch v6 of this action yet.
This pull request tackles a long standing issue with this action: how the action works with branches internally.
Since forever, the action will switch branches locally, if a branch name is provided through the branch-option.
This leads to a slew of problems, when users write workflows, where the repo is checked out using the default branch (main) but the changes are then pushed to a different branch (example-branch-1) (Example: https://github.com/stefanzweifel/git-auto-commit-action/discussions/301).
This annoyed me for a long time. There's no need to check out the given branch locally. A local branch does not have to align with the remote branch in order to push a commit to said remote branch.
We can target the right target branch in the git-push command.
This PR changes this behaviour by removing the _switch_to_branch function completely.
By removing the function, the action also no longer runs git-fetch.
The test suite of the action has been adjusted accordingly. Some tests have been removed. Some tests have been rewritten, as removing the _switch_to_branch function changed the behaviour of the action in certain cases. See "Breaking Changes" section for details.
As this is a breaking change, this change will be released in an upcoming major release (v6) of this Action.
Why I added the current behaviour of switching branches locally is a mistery to me. I probably wrote the code this way, as I personally always mirror the branch names in my local repository with my remote repository. (I would work on a branch called feature-x and push that to origin/feature-x and not origin/development)
Potential Issues
If a user checks out a repository on it's default branch (main), makes changes to the repo and pushes the changes to remote branch example which already exists on remote and has newer commits, the action will fail to push to remote with an error message like this:
Updates were rejected because the remote contains work that you do
not have locally. This is usually caused by another repository pushing
to the same ref. You may want to first integrate the remote changes
(e.g., 'git pull ...') before pushing again.
The solution here will still be, that the user has to solve these "out-of-sync" issues on their own by adding a git-pull or git-rebase step in their workflows.
This pull request tackles a long standing issue with this action: how the action works with branches internally.
Since forever, the action will switch branches locally, if a branch name is provided through the
branch-option. This leads to a slew of problems, when users write workflows, where the repo is checked out using the default branch (main) but the changes are then pushed to a different branch (example-branch-1) (Example: https://github.com/stefanzweifel/git-auto-commit-action/discussions/301).This annoyed me for a long time. There's no need to check out the given branch locally. A local branch does not have to align with the remote branch in order to push a commit to said remote branch. We can target the right target branch in the
git-pushcommand.This PR changes this behaviour by removing the
_switch_to_branchfunction completely. By removing the function, the action also no longer runsgit-fetch.The test suite of the action has been adjusted accordingly. Some tests have been removed. Some tests have been rewritten, as removing the
_switch_to_branchfunction changed the behaviour of the action in certain cases. See "Breaking Changes" section for details.As this is a breaking change, this change will be released in an upcoming major release (v6) of this Action.
Why I added the current behaviour of switching branches locally is a mistery to me. I probably wrote the code this way, as I personally always mirror the branch names in my local repository with my remote repository. (I would work on a branch called
feature-xand push that toorigin/feature-xand notorigin/development)Potential Issues
If a user checks out a repository on it's default branch (
main), makes changes to the repo and pushes the changes to remote branchexamplewhich already exists on remote and has newer commits, the action will fail to push to remote with an error message like this:The solution here will still be, that the user has to solve these "out-of-sync" issues on their own by adding a
git-pullorgit-rebasestep in their workflows.Breaking Changes
TBD
Related Issues
295
TODOs
UPGRADE.md