Re: "GIT_INDEX_FILE" environment variable

LT> ... The fact is, you can do _exactly_ what you are talking LT> about by just wrapping the calls in

LT> 	( cd $WORKING_DIR && git-cmd )

LT> which simply doesn't have any downsides that I can see.

Almost, with a counter-example.  Please try this yourself:

  $ cd mozilla-sha1
  $ echo '/* garbage */' >>sha1.c
  $ sh -c 'cd .. && show-diff "$0" "$@"' sha1.c
  $ cd .. && show-diff mozilla-sha1/sha1.c

Some commands that take working tree relative paths do strange things without the path munging I discussed in the original message ("$R- prefixing") if you chdir to the $WORKING_DIR. The jit-update-cache wrapper I sent in the previous message is an example of how Cogito layer can work it around. It does not break my "yuck" meter but I think it probably makes most people barf ;-). I was trying to make this path munging part easier for the upper layer by making the core aware of WORKING_DIR.

Here is an updated set of commands that needs such path munging:

  check-files paths...
  show-diff [-R] [-q] [-s] [-z] [paths...]
  update-cache [--add] [--remove] [--refresh]
      [--cacheinfo mode blob-id] paths...
  checkout-cache [-f] [-a] paths...

That said, I do not think the above set is too many to warrant a core surgery (I am agreeing with your conclusion here). Unless we also normalize path to support something like:

  $ cd mozilla-sha1
  $ echo '/* garbage */' >>cache.h
  $ sh -c 'cd .. && show-diff "$0" "$@"' ../cache.h

in the core, that is.