Re: [PATCH 0/9] work-tree clean ups

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Wed, 1 Aug 2007, Johannes Schindelin wrote:

> On Tue, 31 Jul 2007, Junio C Hamano wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> > > There is not really much that can be done about step 6/9: if we are in a 
> > > work tree: that does not mean that we are _not_ in the git_dir.  (And no, 
> > > this does not break git-clean, as a work tree is a work tree is a work 
> > > tree.  If the user was stupid enough to specify the same directory as 
> > > GIT_DIR and GIT_WORK_TREE, then that is _her_ problem.  Git is a powerful 
> > > tool, and you can harm yourself with it.  Tough.)
> > 
> > I think we might have a slight misunderstanding.  The "clean"
> > issue that was raised in an ancient thread was this sequence:
> > 
> > 	$ git init
> >         $ cd .git
> >         $ git clean
> > 
> > It did not involve GIT_DIR (nor GIT_WORK_TREE as it was not even
> > there).
> 
> I very much _did_ mean that case.  When "git clean" is run in ".git/", it 
> should not say that it is in the working tree.  But I guess that my patch 
> series is not really looking out for that;  I'll make that an add-on 
> patch.  (But that _will_ have to wait until tomorrow afternoon.)

I should not have answered so early.

In setup.c, I put in a comment that explains clearly where (in the absence 
of GIT_DIR) setup_git_directory_gently() looks for the git directory:

        /*
         * Test in the following order (relative to the cwd):
         * - .git/
         * - ./ (bare)
         * - ../.git/
         * - ../ (bare)
         * - ../../.git/
         *   etc.
         */

At least I hope that this explanation is clear.

So what happens in this case:

	$ git init
	$ cd .git
	$ git clean

In setup_git_directory_gently(), it is tested first if there is a 
subdirectory .git/.  No, none.  Then it is tested if "." is a git 
directory.  Yes!  So, work_tree is set to NULL tentatively (to be 
overridden by either core.worktree or GIT_WORK_TREE), and it is assumed to 
be bare (also subject to overriding).  So all is well!

You might have noticed that I left out --work-tree= handling; when 
--work-tree=<something> is specified, GIT_WORK_TREE is _forced_ to the new 
value, so it is literally handled by the same code as GIT_WORK_TREE.

Ciao,
Dscho