Re: git's fascination with absolute paths

[Avery Pennarun <apenwarr@gmail.com>]

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 to say that it can't be done... just that it seems nobody has been
inspired to do so.  I'm guessing most of the existing developers still
won't be inspired to do it based on your rather unusual use case;
however, they might accept patches.

> Or, perhaps I should be asking, what is there in git that will
> break if I recompile it with make_absolute_path(p){return p;}?
> Does it store absolute paths in the db?  Would a recompiled
> version produce a db other gits couldn't read?

You might try this and then see what happens in 'make test'.  I
imagine a set of clean patches that removed a lot of assumptions about
absolute paths, without breaking any unit tests, would be something
worth considering for integration into git.

Have fun,

Avery