Han Young [off-list ref] writes:

From: Han Young <redacted>

In the ref files backend, the symbolic reference name is not checked
before an update. This could cause reference and lock files to be created
outside the refs/ directory.

Below are the original bug report by Sigma:

  $ echo ref: refs/../HEAD > .git/HEAD
  $ git commit -m "test" --allow-empty
  fatal: cannot lock ref 'HEAD': Unable to create '/home/sigma/headtest/.git/refs/../HEAD.lock': File exists.

  Another git process seems to be running in this repository, e.g.
  an editor opened by 'git commit'. Please make sure all processes
  are terminated then try again. If it still fails, a git process
  may have crashed in this repository earlier:
  remove the file manually to continue.

In this case, while trying to update the symbolic reference refs/../HEAD,
the lock file conflicts with the ./git/HEAD.lock.

If the HEAD points to refs/../foo, a reference file named foo will be
created under ./git directory.

I quickly checked if this can also be done by using 'git-update-ref(1)'.
But the command calls on 'check_refname_format()' to check the new ref
for the symref update and fails:

  $ git update-ref --stdin
  symref-update HEAD refs/../HEAD
  fatal: invalid ref format: refs/../HEAD

So this is only possible by manually editing the .git/HEAD file, right?

In that case, isn't the repository already broken?

In other words, the fix seem to only stop us from creating files outside
the $GIT_DIR, but this seems like something that the user would have to
orchestrate intentionally.

The bigger question for me is if there is an instance that you'd want to
modify the HEAD file manually. Or is there a way this can be done via
any of the existing Git commands. Otherwise, I'm not sure I would call
this a bug.

Han Young (1):
  files-backend: check symref name before update

 refs/files-backend.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

--
2.51.0.373.gaf4ee0e35.dirty