git's fascination with absolute paths

Hi list,

I have a requirement involving the reasonably common Unix-y design pattern where a directory owned by a particular user lives in a directory that user can't access, with a setuid gate that chdirs to the right place and then drops to the real user's id to do certain allowed things.

I wanted to use git for some of those allowed things and I can't, because the code seems to call make_absolute_path on approximately everything, and this is one of the situations that illustrates why it isn't safe to assume you can get an absolute path that's even usable (let alone race-free) corresponding to a relative path in general.

git init tries to do this on the db path (even if it's specified explicitly in GIT_DIR), and even if I do the git init as root in advance, all the other git subcommands I've tried also try to do it and fail when they chdir up out of the working directory and try to chdir (not fchdir) back in.

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?)

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?

(Or less drastic perhaps, what if there were a version of m_a_p that still returned an absolute path when possible and safe, and just returned p otherwise so the program could still be usable?)

Thanks, Chapman Flack mathematics, purdue university