summaryrefslogtreecommitdiff
path: root/copy.c
diff options
context:
space:
mode:
authorLibravatar Michael Haggerty <mhagger@alum.mit.edu>2013-03-18 07:37:32 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2013-03-18 08:06:28 -0700
commitc29c46fa2e21e608ce2e603649af5bf38e7969c2 (patch)
tree80f08454a52aac4afe31b7bf0c7cb9c82bce417a /copy.c
parentpack-refs: write peeled entry for non-tags (diff)
downloadtgif-c29c46fa2e21e608ce2e603649af5bf38e7969c2.tar.xz
pack-refs: add fully-peeled trait
Older versions of pack-refs did not write peel lines for refs outside of refs/tags. This meant that on reading the pack-refs file, we might set the REF_KNOWS_PEELED flag for such a ref, even though we do not know anything about its peeled value. The previous commit updated the writer to always peel, no matter what the ref is. That means that packed-refs files written by newer versions of git are fine to be read by both old and new versions of git. However, we still have the problem of reading packed-refs files written by older versions of git, or by other implementations which have not yet learned the same trick. The simplest fix would be to always unset the REF_KNOWS_PEELED flag for refs outside of refs/tags that do not have a peel line (if it has a peel line, we know it is valid, but we cannot assume a missing peel line means anything). But that loses an important optimization, as upload-pack should not need to load the object pointed to by refs/heads/foo to determine that it is not a tag. Instead, we add a "fully-peeled" trait to the packed-refs file. If it is set, we know that we can trust a missing peel line to mean that a ref cannot be peeled. Otherwise, we fall back to assuming nothing. [commit message and tests by Jeff King <peff@peff.net>] Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'copy.c')
0 files changed, 0 insertions, 0 deletions