Re: git's fascination with absolute paths

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 22, 2009, 00:26 UTC
Message-ID: <7v637z6ehg.fsf@alter.siamese.dyndns.org>
In-Reply-To: <32541b130912211409j540928c0g8e944fcc05c44f82@mail.gmail.com>

Avery Pennarun <apenwarr@gmail.com> writes:

Show 18 quoted lines

> On Mon, Dec 21, 2009 at 1:42 PM, J Chapman Flack <jflack@math.purdue.edu> wrote:
>> In general it seems best for a program to stay free of assumptions
>> about absolute paths except when there is a specific functional
>> requirement that needs them.  I assume there is something git does
>> that requires it to have this limitation, but it's not intuitive
>> to me if I just think about what I expect an scm system to do.
>> I've searched on 'absolute' in the list archive to see if there
>> was a past discussion like "we've decided we need absolute paths
>> everywhere because X" but I didn't find any.  Can someone
>> describe what the reasoning was?  A security concern perhaps?
>> (And one more serious than the race condition built into
>> make_absolute_path?)
>
> I think it's probably just because it's easier to deal with absolute
> paths than relative ones.  Those ".." things can be annoying,
> particularly inside scripts, etc, and git uses a lot of scripts.  Much
> more straightforward to just normalize all the paths once and be sure
> there are no weird dots in them.

Not really. The scripts can work with ".." just fine, as long as they know how to use "cd_to_topdir" and "rev-parse --show-prefix" correctly.

While I do not necessarily agree with the original claim that hiding higher level of hierarchies are "standard" practice in UNIX (it instead falls into "an unusual set-up that is permitted but you have to be careful" category), I don't think it is fundamental that we need read access all the way up to the root level. It is only that getcwd(3) does.

At the basic work tree and index operations operate relative to the root of the work tree. Originally, almost no privision was made to run from a subdirectory of a work tree (you were expected to run from the top-level, having ./.git as the meta information sture), and we didn't have to run any getcwd(3). Later we added "look at parent directories until we find the one that has .git subdirectory, while remembering how many levels we went up", in order to support operations from a subdirectory of a work tree. The commands chdir up to the root of the work tree and would use the path they climbed as a pathspec to limit the scope of their operation.

While "counting how many levels we went up" can be expressed by a sequence of "../", turning it to the directory prefix means at some point you would need to do what getcwd(3) does. It wants to be able to read ".." to give you an absolute path.

By rewriting that part of the "root-level-discovery" code to do something like

 - while test -d .git is not true:
   - stat(".") to get the inum;
   - chdir(".."); and
   - opendir(".") and readdir() to find where we were;

while going up every level, you should be able to construct the prefix without being to able to read all the way up to the filesystem root. You only need to be able to read your work tree.

Admittedly the code complexity got worse later when we added support for GIT_WORK_TREE and also GIT_CEILING_DIRECTORIES, as they fundamentally need to know where you are relative to the root of the filesystem tree and need a working getcwd(3) support, which J Chapman's set-up refuses to give.

Also I wouldn't be surprised if the support for these two features cheat in order to reduce code complexity by always using absolute paths even in places where a path relative to the root of the work tree might have sufficed.