Re: "GIT_INDEX_FILE" environment variable

On Thu, 21 Apr 2005, Junio C Hamano wrote:
> 
> The commands I would want to take paths relative to the user cwd
> are quite limited; note that I just want these available to the
> user and I do not care which one, the core or Cogito, groks the
> cwd relative paths:

I've thought about this, and looked at the sources, and it wouldn't be 
horrible.

HOWEVER, the more I thought about it, the less sense it made. The fact is, 
you can do _exactly_ what you are talking about by just wrapping the calls 
in

	( cd $WORKING_DIR && git-cmd )

which simply doesn't have any downsides that I can see. It always does the 
right thing, and it means that the tools will never have to care about 
what the base is. Keeping the core tools is important, because if they 
mess up, you're in serious trouble. In contrast, if higher levels mess up, 
you're not likely to have caused anything irrevocable.

In fact, I probably shouldn't even have done the "--prefix=" stuff for
check-out, since the common "check out in a new directory" case (not the
"prefix file" case can be pretty easily emulated with a fairly trivial 
script, something like

	#!/bin/sh
	CURRENT_DIR=$(pwd)
	GIT_INDEX_FILE=${GIT_INDEX_FILE:-$CURRENT_DIR/.git/index}
	SHA1_FILE_DIRECTORY=${SHA1_FILE_DIRECTORY:-$CURRENT_DIR/.git/objects}
	TARGET=$1
	shift 1
	mkdir $TARGET && cd $TARGET && checkout-cache "$@"

but since it was (a) very easy to add to that particular program, and (b) 
exporting a while directory is pretty fundamental, I'll just leave that 
strange special case around.

So to the core tools, there really _are_ just two special things: the 
index file, and the place where to find the sha1 objects.  The working 
directory is really nothing but "pwd", which can be trivially changed 
before invocation, ie the addition of a new environment variable really 
doesn't _buy_ anything except for complexity.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html