Home > Enterprise >  Is there a difference in git worktrees on linux and windows runners on github
Is there a difference in git worktrees on linux and windows runners on github

Time:07-01

I have a github action that makes a worktree, copies files to it, and then pushes it to a branch (a different branch than the one the action is on).

When using ubuntu-latest, this works perfectly.

git worktree add -B ghpages html_build origin/ghpages
cp -a docs/. html_build/

cd html_build

git add . 
git commit -m "ghpages"
git push 

When using windows-2019, this fails by trying to push to the current branch instead of the worktree.

git worktree add -B ghpages html_build origin/ghpages
robocopy .\docs\ .\html_build\ /MIR

cd html_build

git add . 
git commit -m "ghpages"
git push 

The error in the action is:

remote: error: GH006: Protected branch update failed for refs/heads/main.        
remote: error: At least 1 approving review is required by reviewers with write access.        
To https://github.com/XXX/XX
 ! [remote rejected]   main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/XXX/XX'

So on linux it correctly pushes to the ghpages branch, on windows it seems to try and push to the main branch, which I have protected. When I remove the protection, it is really just pushing to it (and not the ghpages).

CodePudding user response:

There should be no significant differences between the various Git commands on a Windows or Linux setup, aside from any limitations posed by the OS (e.g., the Windows machine won't be able to check out the files con.py and aux.c). But comparing the two scripts, one thing stuck out for me:

cp -a docs/. html_build/

[vs]

robocopy .\docs\ .\html_build\ /MIR

Not knowing what robocopy might do, I went to https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy which in turn told me that /mir is short for "mirror", which implies /purge. This would remove a .git file like the one git worktree add places into the added working tree. That, in turn, makes this no longer an added working tree, but rather just part of the regular working directory—and the separate branch just vanishes as well.

Switching to /e (instead of /mir) should solve the problem.

  • Related