sha1_file: always allow relative paths to alternates
commit087b6d584062f5b704356286d6445bcc84d686fb
authorJeff King <peff@peff.net>
Mon, 3 Oct 2016 20:36:22 +0000 (3 16:36 -0400)
committerJunio C Hamano <gitster@pobox.com>
Mon, 10 Oct 2016 20:52:37 +0000 (10 13:52 -0700)
treeab349d89bb425a7f0269535ee3c7f44fea6b259d
parent5fe849d651e259af58f29f9cfb1b1405154ffacc
sha1_file: always allow relative paths to alternates

We recursively expand alternates repositories, so that if A
borrows from B which borrows from C, A can see all objects.

For the root object database, we allow relative paths, so A
can point to B as "../B/objects". However, we currently do
not allow relative paths when recursing, so B must use an
absolute path to reach C.

That is an ancient protection from c2f493a (Transitively
read alternatives, 2006-05-07) that tries to avoid adding
the same alternate through two different paths. Since
5bdf0a8 (sha1_file: normalize alt_odb path before comparing
and storing, 2011-09-07), we use a normalized absolute path
for each alt_odb entry.

This means that in most cases the protection is no longer
necessary; we will detect the duplicate no matter how we got
there (but see below).  And it's a good idea to get rid of
it, as it creates an unnecessary complication when setting
up recursive alternates (B has to know that A is going to
borrow from it and make sure to use an absolute path).

Note that our normalization doesn't actually look at the
filesystem, so it can still be fooled by crossing symbolic
links. But that's also true of absolute paths, so it's not a
good reason to disallow only relative paths (it's
potentially a reason to switch to real_path(), but that's a
separate and non-trivial change).

We adjust the test script here to demonstrate that this now
works, and add new tests to show that the normalization does
indeed suppress duplicates.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
sha1_file.c
t/t5613-info-alternate.sh