Resolving Detached Head on Server in Copied "Test" Site and original "Live" Site

Question

Introduction I am managing a Drupal 9.4 site as a novice GIT and composer user, having built it out using these tools and limiting plug-ins to only those I absolutely needed to build out the functionality of my site. I primarily see the need only to upgrade these modules and perhaps one or 2 more as better functionality or security might be needed with module updates. I worked with the site in development for about 6 months and was comfortable that all was well. I then transferred our domain over to it, and asked the host to copy the site so I could also have a functioning test site (I don’t yet have a Docker site configured yet). Then as soon as I considered having composer add Google Analytics, when I went to push the change, I ran into a detached head on the remote server and could not push the change. I discovered that it exists in both the “test” and “live” sites, and I have been trying to resolve it first on the test site, and then I went back to look at the “live” site because I wondered if the problem relates to have a checkout commit on the live site’s repository that is not impactable by anything I do with the test repository.

Error Message upon Push:

xxxxxxxxxxxxxxx public_html % git push origin master
Enumerating objects: 98, done.
Counting objects: 100% (98/98), done.
Delta compression using up to 8 threads
Compressing objects: 100% (88/88), done.
Writing objects: 100% (95/95), 71.96 KiB | 4.80 MiB/s, done.
Total 95 (delta 12), reused 1 (delta 0), pack-reused 0
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: is denied, because it will make the index and work tree inconsistent
remote: with what you pushed, and will require 'git reset --hard' to match
remote: the work tree to HEAD.
remote: 
remote: You can set the 'receive.denyCurrentBranch' configuration variable
remote: to 'ignore' or 'warn' in the remote repository to allow pushing into
remote: its current branch; however, this is not recommended unless you
remote: arranged to update its work tree to match what you pushed in some
remote: other way.
remote: 
remote: To squelch this message and still keep the default behaviour, set
remote: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To ssh://xxxxxxxxxxxxxxxx/ home/customer/www/test.vetmedacademy.org/public_html/
 ! [remote rejected]   master -> master (branch is currently checked out)
error: failed to push some refs to 'ssh://xxxxxxxxxxxxxx/ home/customer/www/xxxxxxxxx/public_html/'

Things I've Tried

1. As I am using Git v. >2.3, I tried. “git config receive.denyCurrentBranch updateInstead” and it still didn’t allow pushing to a non-bare repository.

2. I have reviewed most of the threads here and have tried creating a temporary branch to “capture” the HEAD, and do it on branch on local and then later, the remote server, and after deleting the branch, I am still in a detached head state. Git checkout -b resolveHEAD was used to capture the detached HEAD. Checkout to Master still left me with a detached head.

3. Reverting to the commit (revert HEAD~1) didn’t seem to resolve things either.

Investigating Git Status, Log, Reflog and Rev-Parse

Git Status for Test Site

* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
xxxxxxxxxxxx public_html % 

xxxxxxxxxxxx public_html % git status
On branch master
Your branch is up to date with 'origin/master'.

Git Log for Test Site

nothing to commit, working tree clean
xxxxxxxxxxxx public_html % git log --oneline
960cc571 (HEAD -> master, origin/master, origin/HEAD) remove layout_builder_kit, update hook_event_dispatcher to 3.2^
fb7573ad composer update to core 9.4.4 etc
6cdb8d76 revert commit to core 9.3.15 et al
4a2e92b9 composer updates - core to 9.4.4
9cd36987 upgrade to core 9.3.15 and other module updates
224b5264 Add Layout Builder Styles
ba2f60e8 added Layout Builder Styles stable version
8a7e1782 Upgrade core to 9.3.11 and all required modules in contrib folder
7c5a3877 composer update including core 9.2.7 to 9.30 and all modules in contrib (note: asset injector works in modules dir
021fb342 Initial commit

Git Reflog for Test site (many attempts to fix things-in case I almost corrected things)

xxxxxxxxxxxx public_html % git reflog public_html % git reflog
960cc571 (HEAD -> master, origin/master, origin/HEAD) HEAD@{0}: checkout: moving from master to master
960cc571 (HEAD -> master, origin/master, origin/HEAD) HEAD@{1}: checkout: moving from master to master
960cc571 (HEAD -> master, origin/master, origin/HEAD) HEAD@{2}: reset: moving to origin/master
960cc571 (HEAD -> master, origin/master, origin/HEAD) HEAD@{3}: reset: moving to HEAD~2
e619ad6e HEAD@{4}: commit: remove move of Google Analytics
2d567c56 HEAD@{5}: checkout: moving from master to master
2d567c56 HEAD@{6}: reset: moving to 2d567c56167b87771d3bb866cadd89277cdf0cd6
2d567c56 HEAD@{7}: checkout: moving from master to master
2d567c56 HEAD@{8}: checkout: moving from 960cc571e021eb7888ec708a11983e5e8b0c27d9 to master
960cc571 (HEAD -> master, origin/master, origin/HEAD) HEAD@{9}: checkout: moving from master to origin/master
2d567c56 HEAD@{10}: checkout: moving from temp to master
2d567c56 HEAD@{11}: checkout: moving from master to temp
2d567c56 HEAD@{12}: checkout: moving from 960cc571e021eb7888ec708a11983e5e8b0c27d9 to master
960cc571 (HEAD -> master, origin/master, origin/HEAD) HEAD@{13}: checkout: moving from master to origin
2d567c56 HEAD@{14}: checkout: moving from 960cc571e021eb7888ec708a11983e5e8b0c27d9 to master
960cc571 (HEAD -> master, origin/master, origin/HEAD) HEAD@{15}: checkout: moving from master to origin/master
2d567c56 HEAD@{16}: checkout: moving from master to master
2d567c56 HEAD@{17}: checkout: moving from 960cc571e021eb7888ec708a11983e5e8b0c27d9 to master
960cc571 (HEAD -> master, origin/master, origin/HEAD) HEAD@{18}: checkout: moving from master to origin
2d567c56 HEAD@{19}: checkout: moving from 960cc571e021eb7888ec708a11983e5e8b0c27d9 to master
960cc571 (HEAD -> master, origin/master, origin/HEAD) HEAD@{20}: checkout: moving from master to origin
2d567c56 HEAD@{21}: checkout: moving from master to master
2d567c56 HEAD@{22}: checkout: moving from 960cc571e021eb7888ec708a11983e5e8b0c27d9 to master
960cc571 (HEAD -> master, origin/master, origin/HEAD) HEAD@{23}: checkout: moving from master to origin/master
2d567c56 HEAD@{24}: rebase: checkout master
960cc571 (HEAD -> master, origin/master, origin/HEAD) HEAD@{25}: checkout: moving from master to origin
2d567c56 HEAD@{26}: checkout: moving from 960cc571e021eb7888ec708a11983e5e8b0c27d9 to master
960cc571 (HEAD -> master, origin/master, origin/HEAD) HEAD@{27}: checkout: moving from master to origin/temp
2d567c56 HEAD@{28}: checkout: moving from 960cc571e021eb7888ec708a11983e5e8b0c27d9 to master
960cc571 (HEAD -> master, origin/master, origin/HEAD) HEAD@{29}: checkout: moving from master to origin/master
2d567c56 HEAD@{30}: checkout: moving from master to master
2d567c56 HEAD@{31}: checkout: moving from temp to master
960cc571 (HEAD -> master, origin/master, origin/HEAD) HEAD@{32}: checkout: moving from 960cc571e021eb7888ec708a11983e5e8b0c27d9 to temp
960cc571 (HEAD -> master, origin/master, origin/HEAD) HEAD@{33}: checkout: moving from master to origin
2d567c56 HEAD@{34}: checkout: moving from master to master
2d567c56 HEAD@{35}: commit: add correct Google_Analytics location
960cc571 (HEAD -> master, origin/master, origin/HEAD) HEAD@{36}: clone: from ssh://xxxxxxxxxxx/home/customer/www/xxxxxxxxx/public_html/

Git Rev-Parse for Test Site – all point to same commit currently

xxxxxxxxxxxx public_html % git rev-parse master
960cc571e021eb7888ec708a11983e5e8b0c27d9
xxxxxxxxxxxx public_html % git rev-parse origin/master
960cc571e021eb7888ec708a11983e5e8b0c27d9
xxxxxxxxxxxx public_html % git rev-parse HEAD
960cc571e021eb7888ec708a11983e5e8b0c27d9
xxxxxxxxxxxx public_html % git rev-parse origin/HEAD
960cc571e021eb7888ec708a11983e5e8b0c27d9
xxxxxxxxxxxx public_html % 

What I Found Going Back to Live Site Returning to site that was copied to create this test site…unfortunately, I didn’t check git status before the server host tech team copied the site to create a separate unlinked “test” site (i.e. not as a dev branch but a separate site…mainly because I wanted them separately so I could test freely and not alter the git history of the live site)

Git status for Live Site

xxxxxxxxxxxx public_html % git branch -a
* (HEAD detached at origin/master)
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

HEAD detached at origin/master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   modules/.DS_Store
    modified:   modules/contrib/.DS_Store
    modified:   sites/.DS_Store
    modified:   sites/default/libraries/.DS_Store

Git Log for Live Site

no changes added to commit (use "git add" and/or "git commit -a")
xxxxxxxxxxxx public_html % git log --oneline
960cc571 (HEAD, origin/master, origin/HEAD, master) remove layout_builder_kit, update hook_event_dispatcher to 3.2^
fb7573ad composer update to core 9.4.4 etc
6cdb8d76 revert commit to core 9.3.15 et al
4a2e92b9 composer updates - core to 9.4.4
9cd36987 upgrade to core 9.3.15 and other module updates
224b5264 Add Layout Builder Styles
ba2f60e8 added Layout Builder Styles stable version
8a7e1782 Upgrade core to 9.3.11 and all required modules in contrib folder
7c5a3877 composer update including core 9.2.7 to 9.30 and all modules in contrib (note: asset injector works in modules dir
021fb342 Initial commit

Git Reflog for Live Site

xxxxxxxxxxxx public_html % git reflog
960cc571 (HEAD, origin/master, origin/HEAD, master) HEAD@{0}: checkout: moving from master to origin/master
960cc571 (HEAD, origin/master, origin/HEAD, master) HEAD@{1}: checkout: moving from master to master
960cc571 (HEAD, origin/master, origin/HEAD, master) HEAD@{2}: commit: remove layout_builder_kit, update hook_event_dispatcher to 3.2^
fb7573ad HEAD@{3}: commit: composer update to core 9.4.4 etc
6cdb8d76 HEAD@{4}: commit: revert commit to core 9.3.15 et al
4a2e92b9 HEAD@{5}: commit: composer updates - core to 9.4.4
9cd36987 HEAD@{6}: commit: upgrade to core 9.3.15 and other module updates
224b5264 HEAD@{7}: commit: Add Layout Builder Styles
ba2f60e8 HEAD@{8}: commit: added Layout Builder Styles stable version
8a7e1782 HEAD@{9}: clone: from ssh://xxxxxxx/home/customer/www/xxxxxxx/public_html/
xxxxxxxxxxxx public_html %   

Continuing

As you see from the evaluation of git log, reflog and rev-parsing above, the problem existed as the last commit for the live site’s repository. I don’t seem to be able to resolve either the test site or live site), but git status on the live site at least recognizes the detached head state. It is not seen until you checkout origin/master on the test site.

By the way, all checks show that push and pull would go to and come from this repository. So, git status recognizes the detached remote HEAD here, but not on the copied site.

My ultimate technical questions: Did the copying/cloning process add a tag, ref or branch? (I can find none). And HEAD and all branches are pointing to the last commit. I just seem to be missing something and/or haven’t applied the fixes in a completely correct manner.

Advice if no clear solution And here is a final question, I was hoping to continue to maintain Drupal core and code (plug-in modules) and any dependencies with composer. I do occasionally find a reason to add a patch though. If I am the only one working on the site, should I just return to SFTP? Keeping Git happy seems to occupy an inordinate amount of my time, even when I built this site from ground up so as to understand how it might break! Or should I remove the git folder and reinitiate git for one or both sites, and go on from there? My main interest is in continuing to use composer to upgrade core Drupal and modules.
Thanks for any help and advice you can provide. Duncan

Answer 1

Here is (I think) what you're missing:

• Server repositories should be bare for the reason you've already seen, namely error: refusing to update checked out branch. The checked out branch is the one that is in the server's working tree. A bare repository has no working tree, therefore it never has any checked-out branch, therefore it's always possible to git push to it, at least at this level.

  (The updateInstead setting you tried to use must be set on the server. But if you need an atomic deployment—that is, if the server's state must always be "before update" or "after update", never "halfway through the middle of an update"—then updateInstead mode is not a good idea as it leaves you open to this problem.)

• The HEAD setting is per-repository.¹ That is, each clone has its own HEAD. Using git checkout or git switch determines which branch name, if any, the HEAD name is "attached to". A detached HEAD occurs when HEAD is not attached to any branch name. See more about this below.

  Since it's not possible to use git checkout or git switch in a bare repository,² whatever branch is set as the HEAD at setup time, remains the setup there. When cloning from a server repository, the branch that is the HEAD there—assuming its HEAD is attached—is the "default branch", i.e., the branch name that the server will recommend that the client should check out at the end of a git clone operation, if the client has not picked out a particular branch they want.

• Cloning makes a new repository. This new repository has its own HEAD and its own branch names. Nothing you do here will affect the server's HEAD. However, git push from a client clone, to a server clone, typically ends with a request from the client asking the server to create or update some server branch name(s).

  If the person doing the push has permission to do this—and Git itself has no access controls built in, which is one of many reasons many people prefer to use hosting systems like GitHub or Bitbucket or GitLab here, as those add access controls—then the server will generally obey the request. This updates the server's branch names. This is in fact what you want, but you usually want to have the kinds of control that base Git does not offer.

---

¹Technically, it is per-repository-per-worktree, with one special distinguished HEAD even in a bare repository.

²Unfortunately, it is possible to do this with --work-tree or GIT_WORK_TREE settings, and some number of (low quality) deployment scripts do this. Fortunately, it's common to use this to check out the default branch (master or main, typically), so that the default branch remains the desired default branch. This kind of deployment script also suffers from the same "server might be in halfway through state" at various times. That's one of the things that make this a low quality deployment method.

---

Detaching and attaching HEAD in a non-bare repository

Using git switch (Git 2.23 or later), you simply give Git a branch name. The git switch operation tries to switch to that branch, and if this is successful, HEAD is now attached to that branch name. Giving Git anything that is not a branch name—such as origin/master: this is a remote-tracking name, not a branch name—results in a complaint from git switch. You must use git switch --detach to visit a non-branch-name-identified commit, and this puts you in the detached-HEAD mode.

Using git checkout, however, Git simply assumes you know what you are doing. If you give Git a branch name, it attaches HEAD to that branch name during the checkout. If you give Git a raw hash ID or any non-branch name that suffices to find a commit, Git enters detached-HEAD mode while checking out that commit. (You can add an explicit --detach when using a branch name to force detachment, but most people mostly never want to do that.)

Detaching and attaching head in a bare (server) repository

Git does not have a proper tool for this, but you can use git symbolic-ref (very carefully!) to get the right result. In particular:

git symbolic-ref HEAD refs/heads/master

will "attach" the name HEAD to master. Do not do this in a non-bare repository as you will break the current checkout. You must know exactly what you are doing as Git does not verify this operation.