This is a question about interaction between receive.denyCurrentBranch=updateInstead and worktrees: in regular non-bare repository, using the configuration option mentioned above one can directly deploy code to the folder with the repository, and the manual for git-config seems to encourage that: Another option is "updateInstead" which will update the working tree if pushing into the current branch. This option is intended for synchronizing working directories when one side is not easily accessible via interactive ssh (e.g. a live web site, hence the requirement that the working directory be clean). This mode also comes in handy when developing inside a VM to test and fix code on different Operating Systems. This seems to work with regular checked-out repositories (or "main working tree", as I understand it). I tried using this with "linked" worktrees (created with "git worktree add /some/where some-branch"), it seems to misbehave: the history (git log) in the linked worktree is complete, but files are not changed, an "inverse" change gets staged instead. I am not sure this is not intentional, but it doesn't feel that way. The use case for this would be having a testing and production version on the same server and deploying both by a single 'git push', saving disk space on the way (since the changes are not duplicated in two repositories). Of course, this problem is solvable by using receive hooks and updating the linked worktrees in them. I understand that I have possibly tried to use a combination of features that is uncommon and maybe not tested well enough. I am considering helping with implementing that, but I don't orient well enough in the source code, nor have I read the contribution guidelines yet. Just for the record: The problem I wanted to solve is a bit different. I need to have the .git directory separate from a web deployment in order to be able to simultaneously run the web and have the source code available via a frontend (like Gitea). Since I do not need to have multiple branches deployed, I will try using the updateInstead option with a repository initialized with --separate-git-directory on a server (and if that won't work too, I will probably write another e-mail). Of course, all of the mentioned problems can be solved by having multiple remotes, but I was hoping to make workflows as simple as possible (from the user point of view) -- i.e. not having to remember to publish the source code. Regards, Pavel Turinský
