Re: [RFC/PATCH 4/4] Disallow working directory commands in a bare repository.

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Dec 31, 2006, 15:13 UTC
Message-ID: <Pine.LNX.4.63.0612311606330.22628@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <20061231124921.GA14286@thunk.org>

Hi,

On Sun, 31 Dec 2006, Theodore Tso wrote:

Show 11 quoted lines

> On Sun, Dec 31, 2006 at 12:01:01AM -0800, Junio C Hamano wrote:
> > > Why not just tell these users to setup the working directories with
> > > local .git directories and not use GIT_DIR?
> > 
> > suggest that we might want to bite the bullet and declare that
> > these things are not supported anymore in v1.5.0.
> 
> While we're talking about potentially deprecating GIT_DIR for users,
> out of curiosity, what valid workflows would cause users to want to
> use GIT_INDEX_FILE and GIT_OBJECT_DIRECTORY?  Seems like they would
> cause more confusion and support problems than anything else.

Easy, guys.

It is a valid -- indeed, useful -- thing to be able to script nice helpers. For example, in one project I track tar balls. So, I wrote a script which will unpack the tar ball in a directory, build a new index from it, and commit the corresponding tree on top of the tracking branch. This setup relies _heavily_ on being able to redirect GIT_INDEX_FILE and GIT_DIR.

So, these things are _useful_. Please don't break them.

As for the presence of "index" in a bare repo: I think this is not a problem, _as long_ as things continue to work as before, i.e.

	$ GIT_DIR=$(pwd) git log

and

	$ git --bare log

do _not_ complain if "index" is there. Now, if somebody starts git in a bare repo, where "index" is present, it could die with a helpful message like

	It seems that this is a bare git repository, but there is an index 
	file present, which contradicts that assumption. If the repository
	is indeed bare, please remove the index file.

Ciao, Dscho