packed_ref_store: handle a packed-refs file that is a symlink
authorMichael Haggerty <mhagger@alum.mit.edu>
Wed, 26 Jul 2017 23:39:42 +0000 (16:39 -0700)
committerJunio C Hamano <gitster@pobox.com>
Thu, 27 Jul 2017 17:19:56 +0000 (10:19 -0700)
commit198b808e207e35ba390abe362c75040500997cea
tree6f78b1511253a03eec4956598337cb3b85fb279b
parent9308b7f3ca9bbe7e76b16c832617a8c6aea5ade3
packed_ref_store: handle a packed-refs file that is a symlink

One of the tricks that `contrib/workdir/git-new-workdir` plays is to
making `packed-refs` in the new workdir a symlink to the `packed-refs`
file in the original repository. Before
42dfa7ecef ("commit_packed_refs(): use a staging file separate from
the lockfile", 2017-06-23), a lockfile was used as the staging file,
and because the `LOCK_NO_DEREF` was not used, the pointed-to file was
locked and modified.

But after that commit, the staging file was created using a tempfile,
with the end result that rewriting the `packed-refs` file in the
workdir overwrote the symlink rather than the original `packed-refs`
file.

Change `commit_packed_refs()` to use `get_locked_file_path()` to find
the path of the file that it should overwrite. Since that path was
properly resolved when the lockfile was created, this restores the
pre-42dfa7ecef behavior.

Also add a test case to document this use case and prevent a
regression like this from recurring.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
refs/packed-backend.c
t/t3210-pack-refs.sh