summaryrefslogtreecommitdiff
path: root/graph.c
diff options
context:
space:
mode:
authorLibravatar Michael Haggerty <mhagger@alum.mit.edu>2017-07-26 16:39:42 -0700
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-07-27 10:19:56 -0700
commit198b808e207e35ba390abe362c75040500997cea (patch)
tree6f78b1511253a03eec4956598337cb3b85fb279b /graph.c
parentread_packed_refs(): die if `packed-refs` contains bogus data (diff)
downloadtgif-198b808e207e35ba390abe362c75040500997cea.tar.xz
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>
Diffstat (limited to 'graph.c')
0 files changed, 0 insertions, 0 deletions