You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Then if pull is used, the file is also removed here which breaks the action, since the file is already marked as removed.
::error::Error: fatal: pathspec 'file-that-was-removed.txt' did not match any files
::error::Error: Remove command did not match any file:%0A git rm file-that-was-removed.txt
If one wants to rebase it does not make sense that the commit is done after the pull. The commit should be done, then a pull rebase should happen, that would not break the flow.
I guess it's hard to account for these different approaches.
The text was updated successfully, but these errors were encountered:
You're probably right, but honestly I'm afraid that if I change that behavior then I'm going to break someone else's workflow :/
It's not destructive, since I'd use a new major version, but it would mean that then someone else could open an issue like this...
I don't know, do you think there's a way to make everyone happy about this? 😅
😅 I don't think a workaround for this specific situation is good. I think it's reasonable to expect that a commit needs to be done before another pull is done.
If people use this action to say "ignore everything that has happened in origin, I just really want these files removed, then the workflow is flawed.
Currently a user can:
Remove all *.md files
Only README.md was removed
git pull => now there is a IMPORTANT-NOTE.md
Remove all *.md files
Now the README.md and the IMPORTANT-NOTE.md is removed
I think it's reasonable to encourage the user to fix the conflict somehow, and not just hide it. If the commit is done just after the first round of add/remove, then those changes are clearly described. Then follows a potential pull or pull --rebase which describes where in the history they'd want their commit. If there are any conflicts between your commit and any new commits in origin, you will be notified of the conflict since the action will fail.
Consider this:
First the file is removed here
Then if
pull
is used, the file is also removed here which breaks the action, since the file is already marked as removed.If one wants to rebase it does not make sense that the commit is done after the pull. The commit should be done, then a pull rebase should happen, that would not break the flow.
I guess it's hard to account for these different approaches.
The text was updated successfully, but these errors were encountered: