diff options
author | Michael Haggerty <mhagger@alum.mit.edu> | 2013-03-18 07:37:32 -0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2013-03-18 08:06:28 -0700 |
commit | c29c46fa2e21e608ce2e603649af5bf38e7969c2 (patch) | |
tree | 80f08454a52aac4afe31b7bf0c7cb9c82bce417a /test-sha1.c | |
parent | pack-refs: write peeled entry for non-tags (diff) | |
download | tgif-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 'test-sha1.c')
0 files changed, 0 insertions, 0 deletions