From: Petr Baudis Date: Tue, 10 May 2005 00:44:31 GMT Subject: Re: [RFC] Renaming environment variables. Message-ID: <20050510004431.GM15712@pasky.ji.cz> In-Reply-To: Dear diary, on Tue, May 10, 2005 at 02:38:53AM CEST, I got a letter where Daniel Barkalow told me that... > On Mon, 9 May 2005, Junio C Hamano wrote: > > > >>>>> "DB" == Daniel Barkalow writes: > > > > DB> While we're at it, it would be useful to have one for what is normally > > DB> ".git",... > > > > If you mean the parent directory of ${SHA1_FILE_DIRECTORY}, and > > your only gripe is about git-init-db creating ".git" in the > > current working directory regardless of SHA1_FILE_DIRECTORY, I > > would agree that what git-init-db does is broken. Not that I > > have a suggested "right behaviour" for it, though. > > It could just create all missing parents of the object directory, which > would be better, at least. What about the index file? Or should git-read-tree take care of that? > But even if this is up to the wrapping scripts, it would be useful to have > the same environment variable used by those scripts for whatever they want > to have in there. Seconded. That is another good reason for having that. > > I once advocated GIT_WORKING_TREE to mean the current project > > top, which is the parent directory of ".git". The proposal was > > shot down (see archives [*1*]). While I still think that > > configuration (or your ".git" location proposal, which is > > essentially the equivalent) may sometimes useful, I'd rather not > > conflate this environment variable renames with that issue. > > They are pretty much independent issues. > > The reason to tackle them at once is so that there doesn't have to be > multiple changeovers. There should be no changeovers, just additions - the object directory and index file location environment variables should stay too. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor