Re: "GIT_INDEX_FILE" environment variable

From: Zach Welch <zw@superlucidity.net>
Date: Apr 22, 2005, 09:14 UTC
Message-ID: <4268C070.3010706@superlucidity.net>
In-Reply-To: <Pine.LNX.4.58.0504212200400.2344@ppc970.osdl.org>

Howdy,

Linus Torvalds wrote:

Show 10 quoted lines

> 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