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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
