"GIT_INDEX_FILE" environment variable

"GIT_INDEX_FILE" environment variable

[Linus Torvalds]

This checkin goes along with the previous one, and makes it easier to use 
all the normal git operations on temporary index files:

  Add support for a "GIT_INDEX_FILE" environment variable.
  
  We use that to specify alternative index files, which can be useful
  if you want to (for example) generate a temporary index file to do
  some specific operation that you don't want to mess with your main
  one with.
  
  It defaults to the regular ".git/index" if it hasn't been specified.

and it's particularly useful for doing things like "read a tree into a 
temporary index file, and write the result out". For example, say that you 
wanted to know what the Makefile looked like in a particular release, 
you could do

    GIT_INDEX_FILE=.tmp-index read-tree $release
    GIT_INDEX_FILE=.tmp-index checkout-cache --prefix=old- Makefile
    rm .tmp-index

and you're done. Your old Makefile version is now in "old-Makefile" (and
this is also where it's nice that checkout-cache refuses to overwrite
existing files by default: if you forgot or messed up the prefix, it's all
good).

You can also use it to test merges without screwing up your old index file 
in case something goes wrong.

Did I already happen to mention that I think that the git model is the
best model ever, and that I'm just not an incredibly good-looking hunk and
becomingly modest, I'm smart too?

		Linus

Re: "GIT_INDEX_FILE" environment variable

[Davide Libenzi]

On Thu, 21 Apr 2005, Linus Torvalds wrote:

> Did I already happen to mention that I think that the git model is the
> best model ever, and that I'm just not an incredibly good-looking hunk and
> becomingly modest, I'm smart too?

You forgot, *again*, to take your medications !!



- Davide

Re: "GIT_INDEX_FILE" environment variable

[Linus Torvalds]

On Thu, 21 Apr 2005, Linus Torvalds wrote:
> 
> You can also use it to test merges without screwing up your old index file 
> in case something goes wrong.

Btw, if it wasn't obvious, for the merge thing to work you need to first
copy the old index file _or_ generate a new temporary index file first, so
that doing the three-way merge has a previous index file to work with. Ie
it would look something like

	cp .git/index .tmp-index
	GIT_INDEX_FILE=.tmp-index read-tree -m $orig $branch1 $branch2

but this same approach can also be used to merge things _without_ actually
having any specific version checked out, in which case it would just be

	GIT_INDEX_FILE=.tmp-index read-tree $orig
	GIT_INDEX_FILE=.tmp-index read-tree -m $orig $branch1 $branch2

which allows you to create a merged index file that is totally independent 
on whatever (if anything) you happen to be working on right now.

Together with a SHA1_FILE_DIRECTORY, it allows you to do merges entirely
outside any real git tree, and without any other setup. That's quite nice
for the case where your actual working tree may be dirty, and you don't
want to mess around in it.

			Linus

Re: "GIT_INDEX_FILE" environment variable

[Junio C Hamano]

>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:

LT>   Add support for a "GIT_INDEX_FILE" environment variable.
  
LT>   We use that to specify alternative index files, which can be useful
LT>   if you want to (for example) generate a temporary index file to do
LT>   some specific operation that you don't want to mess with your main
LT>   one with.
  
LT>   It defaults to the regular ".git/index" if it hasn't been specified.

This is all good.  I have a related issue I'd like to hear your
opinion about.

When I am not in the top-level directory, relative to the tree
structure $GIT_INDEX_FILE describes, obviously I cannot just say
"show-diff path-pattern" (or even just "show-diff") without
first chdir'ing to the top.  My current workaround I use in the
jit-show-diff wrapper script is quite ugly:

 - Starting from dir="${PWD-"$(pwd)"}", repeatedly do
   dir=$(dirname dir) until I find a $dir/.git directory.  Call
   the first directory I find that has .git subdirectory
   $GIT_PROJECT_TOP.

 - At the same time, inspect GIT_INDEX_FILE and
   SHA1_FILE_DIRECTORY environment variables.  If they are not
   set, set them to $GIT_PROJECT_TOP/.git/index and
   $GIT_PROJECT_TOP/.git/objects, respectively and export them.

 - Figure out the name of the current working directory relative
   to $GIT_PROJECT_TOP.  I'll call this value $R for brevity in
   the following description.

 - chdir to $GIT_PROJECT_TOP and run "show-diff" with the
   original flags and _all_ the user supplied paths prefixed
   with $R.

To illustrate what I just said:

  $ /bin/ls -aF
  ./  ../  .git/  a/
  $ /bin/ls -aF .git
  .   ../  HEAD   index  objects/ 
  $ cd a
  $ /bin/ls -aF
  .   ../   bar  foo/
  $ show-diff -r foo     ; # of course this does not work.
  $ jit-show-diff -r foo

  The wrapper figures out that .. is the project top to chdir
  to, and $R is "a/".  Using these values, it eventually calls:

    cd .. ; show-diff -r "a/foo"

This is not so hard to arrange in the wrapper, but this is quite
brittle.  The show-diff command happens to take only -r, -z, and
-q flag parameters so the wrapper can prefix $R to all the other
paramters, but for other git core commands when to prefix $R and
when not to soon becomes a maintenance nightmare.

I am thinking about an alternative way of doing the above by
some modifications to the git core.  I think the root of this
problem is that there is no equivalent to GIT_INDEX_FILE and
SHA1_FILE_DIRECTORY that tells the core git where the project
top directory (i.e. the root of the working tree that
corresponds to what $GIT_INDEX_FILE describes) is.

I am wondering if this alternative is acceptable by you before I
spend too much time on it.

 - A new environment variable GIT_WORKING_TREE points at the
   root of the working tree.

 - Each git core command [*1*] that looks at the working tree is
   modified to take the user supplied pathname as a path
   relative to the current working directory, and use
   GIT_WORKING_TREE value to figure out which path the user is
   talking about, relative to the tree structure GIT_INDEX_FILE
   describes.

There is no need for jit-show-diff-wrapper when the above change
happens.  The user (or Cogito) has to set and export
GIT_WORKING_TREE once, and whereever the user happens to be the
core git command would just work as expected.

What do you think?


[Footnotes]

*1* Yes I am aware that there are tons of them that need this
surgery if we wanted to take this approach.

Re: "GIT_INDEX_FILE" environment variable

[Linus Torvalds]

On Thu, 21 Apr 2005, Junio C Hamano wrote:
> 
> I am thinking about an alternative way of doing the above by
> some modifications to the git core.  I think the root of this
> problem is that there is no equivalent to GIT_INDEX_FILE and
> SHA1_FILE_DIRECTORY that tells the core git where the project
> top directory (i.e. the root of the working tree that
> corresponds to what $GIT_INDEX_FILE describes) is.

I'd _really_ prefer to just try to teach people to work from the "top" 
directory instead.

>  - A new environment variable GIT_WORKING_TREE points at the
>    root of the working tree.
> 
>  - Each git core command [*1*] that looks at the working tree is
>    modified to take the user supplied pathname as a path
>    relative to the current working directory, and use
>    GIT_WORKING_TREE value to figure out which path the user is
>    talking about, relative to the tree structure GIT_INDEX_FILE
>    describes.

I really don't like it that much, but to some degree it obviously is
exactly what "--prefix=" does to checkout-cache. It's basically saying 
that all normal file operations have to be prefixed with a magic string. 

And git really doesn't do too many of those, so maybe it's ok. What would 
the patch look like? I don't really love the idea, but if the patch is 
clean enough...

		Linus

Re: "GIT_INDEX_FILE" environment variable

[Junio C Hamano]

>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:

LT> I'd _really_ prefer to just try to teach people to work from
LT> the "top" directory instead.

I share the sentiment, but I do not think that is an option.
There are three possibilities:

 - Train people to always work from the top and never support
   working in subdirectory at any layer.

 - Admit that people cannot be trained, and support it at Cogito
   layer.

 - Further admit that to support it without core layer help,
   what Cogito layer needs to do involves quite a lot of "yuck"
   factor.

For somebody whose primary concern is to pull the whole tree
from outside and watch out for merge conflicts, always working
from the top may be a practical option.  But you also have to
consider that the people who actually feed those whole trees to
you probably do most of their work in their subdirectories.  You
would want to make life easier for them in order for you to get
high-quality results from them.

I initially thought that the third one in the above list was the
case, and that's why I asked.  After reviewing the core layer to
see the extent of the damage the proposed change would cause, to
my surprise, it turns out that it is not all that bad.  It
probably is not surprising to you because of the way you
designed things --- doing as much as possible in the dircache,
and avoiding looking at the working tree.

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:

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

The only parameters that needs $R prefixing are the "paths..."
above.  I think the wrapper layer can manage without the help
from the core layer for these small number of commands using the
workaround I outlined in my previous message.

In addition, there is another one that looks at the working
tree:

  diff-cache [-z] [-r] [--cached] tree-id

But this one is even easier.  The wrapper layer needs to figure
out the project top, chdir to it and run the underlying
diff-cache there.

LT> I really don't like it that much, but to some degree it
LT> obviously is exactly what "--prefix=" does to
LT> checkout-cache. It's basically saying that all normal file
LT> operations have to be prefixed with a magic string.

More or less so.  I actually was thinking about going a bit more
than just prefix, and normalizing paths in the core layer, in
order to get something like the following operate sensibly:

  $ find . -type f | xargs update-cache
  $ cd mozilla-sha1 && show-diff ../*.h

But this may be going a bit overboard.

LT> And git really doesn't do too many of those, so maybe it's
LT> ok. What would the patch look like? I don't really love the
LT> idea, but if the patch is clean enough...

Please forget this one for a bit.  I'm attacking this from both
fronts.

Core changes supporting the "project root" notion is what we are
discussing here.  As I said, I do not think it would be a huge
change as I feared initially, but after the initial "let's get
the list of commands and analyze how they use the paths" phase,
I have backburnered this approach, at least for now.  Working
around in the wrapper layer without core support seems to be a
viable option, especially now I know that what needs to be
wrapped are not that many, and that is what I've been looking
at this evening.

For your amusement, eh, rather, to test your "yuck" tolerance
;-), I've attached two scripts.  jit-find-index is a helper
script for wrappers.  It finds the project root and computes $R
prefix; the wrappers call it and eval its result.
jit-update-cache is a wrapper to run update-cache inside of
subdirectory.  This is the worst example among the four wrappers.

Not-Signed-off-yet-by: Junio C Hamano <junkio@cox.net>
---

 jit-find-index   |   60 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 jit-update-cache |   23 +++++++++++++++++++++
 2 files changed, 83 insertions(+)

--- /dev/null	2005-03-19 15:28:25.000000000 -0800
+++ jit-find-index	2005-04-21 22:59:55.000000000 -0700
@@ -0,0 +1,60 @@
+#!/bin/sh
+
+sq=s/\'/\''\\'\'\'/g ;# see sq-expand in show-diff.c
+
+lookfor_index=${GIT_INDEX_FILE-.git/index}
+lookfor_object=${SHA1_FILE_DIRECTORY-.git/objects}
+
+index= object= project_top=
+
+# No point in looking for something specified with an absolute path.
+case "$lookfor_index" in
+/*) index="$lookfor_index" ;;
+esac
+case "$lookfor_object" in
+/*) object="$lookfor_object" ;;
+esac
+
+# Beware of symlinks.  We need to find out what the current directory
+# is called relative to the path recorded in the dircache.
+dir=${PWD-$(pwd)} cwd="$dir" down=
+
+while 
+    case "$dir" in /) break ;; esac && # we searched all.
+    case ",$index,$object,$project_top," in
+    *,,*) ;;
+    *)    break ;; # we now have all.
+    esac
+do
+    case "$index" in
+    '') test -f "$dir/$lookfor_index" &&
+	index="$dir/$lookfor_index" ;;
+    esac
+    case "$object" in
+    '') test -d "$dir/$lookfor_object" &&
+	object="$dir/$lookfor_object" ;;
+    esac
+
+    case "$project_top" in
+    '') test -d "$dir/.git" &&
+	project_top="$dir" &&
+	working_dir="$down" ;;
+    esac
+    down="$(basename "$dir")/$down"
+    dir=$(dirname "$dir")
+done
+
+if test ! -f "$index" || test ! -d "$object" || test ! -d "$project_top"
+then
+    echo >&2 \
+      "Cannot find the project top, index file, or object database."
+    echo exit 1 ;# love this!
+else
+    # Working directory relative to the project top
+
+    echo "GIT_INDEX_FILE='$(echo "$index" | sed -e "$sq")'"
+    echo "SHA1_FILE_DIRECTORY='$(echo "$object" | sed -e "$sq")'"
+    echo "GIT_PROJECT_TOP='$(echo "$project_top" | sed -e "$sq")'"
+    echo "GIT_WORKING_DIR='$(echo "$working_dir" | sed -e "$sq")'"
+    echo export GIT_INDEX_FILE SHA1_FILE_DIRECTORY GIT_PROJECT_TOP
+fi



--- /dev/null	2005-03-19 15:28:25.000000000 -0800
+++ jit-update-cache	2005-04-21 22:59:48.000000000 -0700
@@ -0,0 +1,23 @@
+#!/bin/sh
+
+eval "$(jit-find-index)"
+sq=s/\'/\''\\'\'\'/g
+RQ=$(echo "$GIT_WORKING_DIR" | sed -e "$sq")
+args=
+while case "$#" in 0) break ;; esac
+do
+	case "$1" in
+	--add | --remove | --refresh)
+	    args="${args}$1 " ;;
+	--cacheinfo)
+	    args="${args}$1 "
+	    shift; args="${args}'$(echo "$1" | sed -e "$sq")' "
+	    shift; args="${args}'$(echo "$1" | sed -e "$sq")' " ;;
+	*)
+	    args="${args}'$RQ$(echo "$1" | sed -e "$sq")' " ;;
+	esac
+	shift
+done
+eval "set x $args; shift"
+
+cd $GIT_PROJECT_TOP && exec update-cache "$@"

Re: "GIT_INDEX_FILE" environment variable

[Petr Baudis]

Dear diary, on Fri, Apr 22, 2005 at 08:23:41AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> >>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
>  - Further admit that to support it without core layer help,
>    what Cogito layer needs to do involves quite a lot of "yuck"
>    factor.

I actually thought that I would just walk to parent directories at the
time of invocation, to find the .git directory, then save that to
$gitdir and use that to always reference to it, setting also
GIT_INDEX_FILE etc. I basically just postponed this until I have some
kind of library or something, and do all this stuff in a single common
init routine. I think it should be doable pretty well in Cogito alone,
but of course I won't mind if someone does it in git core. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: "GIT_INDEX_FILE" environment variable

[Linus Torvalds]

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

Re: "GIT_INDEX_FILE" environment variable

[Junio C Hamano]

>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:

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.

Re: "GIT_INDEX_FILE" environment variable

[Linus Torvalds]

On Fri, 22 Apr 2005, Junio C Hamano wrote:
> 
> Almost, with a counter-example.  Please try this yourself:

I agree that what git outputs is always "based on the archive base". But 
that's an independent issue from "where is the working directory". That's 
the issue of "how do you want me to print out the results".

To see just how independent that is, think about how git-pasky (and,
indeed, standard "show-diff") already prints out the results in a
_different_ base than the working directory _or_ the base. Ie the way we 
already do

	--- a/Makefile
	+++ b/Makefile
	... patch ...

for a patch to "Makefile" in the top-level directory.

IOW, showing pathnames is different from _using_ them. And if you were 
planning on using the same logic for both, you'd have been making a 
mistake in the first place.

To _use_ pathnames, you use "pwd". To _show_ them, you use some other
mechanism. You must not mix up those two issues, or you'd always get
"show-diff" wrong.

I actually think that showing the pathnames is up to the wrapper scripts. 
Git core really always just works on the "canonical" format.

(And I personally think that "show-diff" is really part of the "wrapper
scripts" around git. I wrote it originally just because I needed something
to verify the index file handling, not because it's "core" like the other
programs. I do _not_ consider "show-diff" to be part of the core git code,
really. Same goes for "git-export", btw - for the same reasons. It's not
"fundamental").

		Linus

Re: "GIT_INDEX_FILE" environment variable

[Junio C Hamano]

>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:

LT> On Fri, 22 Apr 2005, Junio C Hamano wrote:
>> 
>> Almost, with a counter-example.  Please try this yourself:

LT> I agree that what git outputs is always "based on the archive base". But 
LT> that's an independent issue from "where is the working directory".

I am not talking about output, but the input.  I do not mind
(and I rather prefer) the output is always canonical.

Re: "GIT_INDEX_FILE" environment variable

[Petr Baudis]

Dear diary, on Sat, Apr 23, 2005 at 12:14:16AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> (And I personally think that "show-diff" is really part of the "wrapper
> scripts" around git. I wrote it originally just because I needed something
> to verify the index file handling, not because it's "core" like the other
> programs. I do _not_ consider "show-diff" to be part of the core git code,
> really. Same goes for "git-export", btw - for the same reasons. It's not
> "fundamental").

Note that Cogito almost actually does not use show-diff anymore.
I'm doing diff-cache now, since that is what matters to me.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: "GIT_INDEX_FILE" environment variable

[Linus Torvalds]

On Sat, 23 Apr 2005, Petr Baudis wrote:
> 
> Note that Cogito almost actually does not use show-diff anymore.
> I'm doing diff-cache now, since that is what matters to me.

Indeed.  "diff-tree" (between releases) and "diff-cache" (between a
release and the current state) are clearly much more fundamental
operations.

Also, they have absolutely zero policy, and they're designed to be used
with the same scripting engines (ie hopefully you can use just one tool to
show the output of either in whatever format you want).

They show you what the canonical names and associated information is, and
that's it. What you _do_ with them ends up being outside the scope of git,
exactly like it should be. Details like "what format of diff" to produce 
should be left to the tools around it.

In contrast, "show-diff" was _literally_ written to check what the
difference between the "real" file and a "sha1"  file was, back when I
couldn't write the sha1 files correctly (ie I corrupted anything that 
didn't fit in the first "[un]compression block", and then calling "diff" 
to show the difference between the original and the regenerated data was 
very important).

So "show-diff" just kind of expanded from an early debugging tool to
something that _almost_ looks like a real tool. But it's absolutely the
right thing to use "diff-tree" and "diff-cache" instead.

			Linus

Re: "GIT_INDEX_FILE" environment variable

[Zach Welch]

Howdy,

Linus Torvalds wrote:
> On Thu, 21 Apr 2005, Junio C Hamano wrote: 
>>I am thinking about an alternative way of doing the above by
>>some modifications to the git core.  I think the root of this
>>problem is that there is no equivalent to GIT_INDEX_FILE and
>>SHA1_FILE_DIRECTORY that tells the core git where the project
>>top directory (i.e. the root of the working tree that
>>corresponds to what $GIT_INDEX_FILE describes) is.
> 
> I'd _really_ prefer to just try to teach people to work from the "top" 
> directory instead.

Would it be okay if that were settable on a per-repository basis? :)
Or do you have specific subset of operations you want restricted?

>> - A new environment variable GIT_WORKING_TREE points at the
>>   root of the working tree.
[snip]
> I really don't like it that much, but to some degree it obviously is
> exactly what "--prefix=" does to checkout-cache. It's basically saying 
> that all normal file operations have to be prefixed with a magic string. 

I'm going to script it one way or the other, but the environment route
allows me to set things up after a fork and before exec in Perl. This
works regardless of what git command I'm running, and should work even
with ithreads. This ease of use would not be the case with the
'--prefix' solution, as scripting the commands would requiring passing
arguments to those commands that need/support them at a higher level
than is desirable.

At present, I have implemented Yogi to support being able to run
commands from a different working directory than the root of the
repository, and that behavior might be per-repository settable
(someday). If I had my way, I would like to see git support the
following variables:

  GIT_WORKING_DIRECTORY   - default to '.'
  GIT_CACHE_DIRECTORTY    - default to ${GIT_WORKING_DIRECTORY}/.git
  GIT_OBJECT_DIRECTORY    - defaults to ${GIT_CACHE_DIRECTORY}/objects

The reasoning is simple: One object repository can be shared among
numerous working caches, which can be shared among multiple working
directories (e.g. any directories under the project root, but maybe also
import/exports, or other magic...). There are two layers of one to many
relationships between the three classes of directories, and my scripts
want to make use of that flexibility to the hilt.

Also, do you really think git will only ever have the index file, and
not someday possibly other related bits? (You may have said that
elsewhere, but I missed it.) If that's ever the case, the directory
variable is the way to go; scripts can be forward compatible and won't
risk accidentally mingling repository data when their scripts have only
set GIT_INDEX_FILE and not GIT_SOME_OTHER_FILE.

That said, I think GIT_INDEX_FILE would supplement the above scheme
nicely, overriding a default of ${GIT_CACHE_DIRECTORY}/index, because of
use cases you've described.

Cheers,

Zach