# Relative alternates question

2 messages from 2007-08-10 to 2007-08-10. Participants: Jan Hudec, Junio C Hamano.
Thread: https://gitlist.dev/t/9475

## Jan Hudec, 2007-08-10 16:45

Subject: Relative alternates question
Message-ID: <20070810164556.GB3442@efreet.light.src>
URL: https://gitlist.dev/e/20070810164556.GB3442%40efreet.light.src

```
Hello,

Trying to solve a problem with object/info/alternates and http (a rather
problematic combination) I noticed the following code in sha1_file.c:336 in
function link_alt_odb_entries.
(current master -- v1.5.3-rc4-41-g7efeb8f):

                        if ((*last != '/') && depth) {
                                error("%s: ignoring relative alternate object store %s",
                                                relative_base, last);
                        } else {
                                link_alt_odb_entry(last, cp - last,
                                                relative_base, depth);
                        }

The last is (if I understood the code correctly) begining of line, cp is end
of that line and depth is depth of recursion in resolving the alternates. Now
unless I read the code completely wrong, it means, that when git reads
a repository, it resolves relative paths in it's objects/info/alternates, but
if that contains further alternates, it would ignore relative alternate paths
there -- and therefore not find objects needed from there.

And my question is, is there any good reason to reject relative paths in
alternates of an alternate? From what I see the recursive call to
link_alt_odb_entries (via link_alt_odb_entry and read_info_alternates) has
all the information it needs to resolve such paths.

Thanks,

Jan

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

```

## Junio C Hamano, 2007-08-10 19:38

Subject: Re: Relative alternates question
Message-ID: <7vfy2rrxh1.fsf@assigned-by-dhcp.cox.net>
URL: https://gitlist.dev/e/7vfy2rrxh1.fsf%40assigned-by-dhcp.cox.net
In-Reply-To: <20070810164556.GB3442@efreet.light.src>

```
Jan Hudec <bulb@ucw.cz> writes:

> And my question is, is there any good reason to reject relative paths in
> alternates of an alternate? From what I see the recursive call to
> link_alt_odb_entries (via link_alt_odb_entry and read_info_alternates) has
> all the information it needs to resolve such paths.

As long as you are careful not to introduce loops that cause the
rest of the code to add the same thing twice, I do not think
there is anything fundamentally wrong with relative alternate
paths.  The original motivation of that check was not much more
than "let's not complicate our lives by supporting it", I think.

```