{"thread":{"id":"52926","subject":"Updating linked working trees when receiving packs","startedAt":"2020-03-02T10:42:30Z","lastAt":"2020-03-02T10:42:30Z","messageCount":1,"participants":["Pavel Turinsky"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"392738","messageId":"d3524560-97cb-e36a-49f1-0c17e5be545c@matfyz.cz","threadId":"52926","inReplyTo":null,"subject":"Updating linked working trees when receiving packs","fromName":"Pavel Turinsky","fromEmail":"pavel.turinsky@matfyz.cz","sentAt":"2020-03-02T10:36:54Z","receivedAt":"2020-03-02T10:42:30Z","isPatch":false,"sender":{"key":"pavel.turinsky@matfyz.cz","avatar":null},"body":"This is a question about interaction between\nreceive.denyCurrentBranch=updateInstead and worktrees: in regular\nnon-bare repository, using the configuration option mentioned above one\ncan directly deploy code to the folder with the repository, and the\nmanual for git-config seems to encourage that:\n\n\tAnother option is \"updateInstead\" which will update the working\n\ttree if pushing into the current branch. This option is intended\n\tfor synchronizing working directories when one side is not\n\teasily accessible via interactive ssh (e.g. a live web site,\n\thence the requirement that the working directory be clean). This\n\tmode also comes in handy when developing inside a VM to test and\n\tfix code on different Operating Systems.\n\nThis seems to work with regular checked-out repositories (or \"main\nworking tree\", as I understand it). I tried using this with \"linked\"\nworktrees (created with \"git worktree add /some/where some-branch\"), it\nseems to misbehave: the history (git log) in the linked worktree is\ncomplete, but files are not changed, an \"inverse\" change gets staged\ninstead. I am not sure this is not intentional, but it doesn't feel that\nway.\n\nThe use case for this would be having a testing and production version\non the same server and deploying both by a single 'git push', saving\ndisk space on the way (since the changes are not duplicated in two\nrepositories). Of course, this problem is solvable by using receive\nhooks and updating the linked worktrees in them.\n\nI understand that I have possibly tried to use a combination of features\nthat is uncommon and maybe not tested well enough. I am considering\nhelping with implementing that, but I don't orient well enough in the\nsource code, nor have I read the contribution guidelines yet.\n\nJust for the record: The problem I wanted to solve is a bit different.\nI need to have the .git directory separate from a web deployment in\norder to be able to simultaneously run the web and have the source code\navailable via a frontend (like Gitea). Since I do not need to have\nmultiple branches deployed, I will try using the updateInstead option\nwith a repository initialized with --separate-git-directory on a server\n(and if that won't work too, I will probably write another e-mail).\n\nOf course, all of the mentioned problems can be solved by having\nmultiple remotes, but I was hoping to make workflows as simple as\npossible (from the user point of view) -- i.e. not having to remember to\npublish the source code.\n\nRegards,\nPavel Turinský\n"}]}