Re: [PATCH 0/9] work-tree clean ups
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Aug 1, 2007, 10:56 UTC
- Message-ID
- <Pine.LNX.4.64.0708011147500.14781@racer.site>
- In-Reply-To
- <Pine.LNX.4.64.0708010211071.14781@racer.site>
Hi,
On Wed, 1 Aug 2007, Johannes Schindelin wrote:
Show 25 quoted lines
> 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