Updating linked working trees when receiving packs

Updating linked working trees when receiving packs

[Pavel Turinsky]

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ý