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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 1, 2007, 00:55 UTC
Message-ID: <7vbqdsdqfd.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0708010058130.14781@racer.site>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 6 quoted lines

> 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). The point was that not all subdirectories of the toplevel (i.e. the directory on the filesystem that corresponds to the root level of your index entries and trees contained in your commits) were safe to answer yes when asked "are we safe to perform this worktree oriented command here". Because no trees nor index would have .git/ subdirectory tracked, "git clean" will happily remove everything under .git/ (which is $cwd in the above sequence).

I personally feel that the above sequence is a pilot error and not worth worrying about, but as people wanted to have that extra safety, and as we added that (arguably stupid) safety way before the WORK_TREE stuff, we should mention it if we are changing the behaviour and lifting it with this patch series.

Show 5 quoted lines

> Note: if you are in a bare repository (a repository which either says 
> "core.bare = false" in the config, or which is a direct ancestor 
> directory, i.e. ../[...]/.. of the current working directory) there will 
> _not_ be an automatic working directory assignment.  You will be operating 
> _without_ any work tree, unless you specify one.

Sorry, I cannot interpret the condition part of the sentence, nor "There will _not_ be an automatic assignment" part.

By the latter, do you mean to say your $cwd is assumed to be the top of the working tree unless GIT_WORK_TREE or core.worktree, if you are in a bare repository? Or it is assumed that you do not have a worktree and worktree oriented operations that require a worktree such as "git diff-files" and "git status" will fail?

> I somehow feel that core.bare = true weighs more than core.worktree = 
> /some/thing, and therefore I implemented it that way, but hey, if enough 
> people disagree, then I'll change it.

Personally, I think

 [core]
     bare = true
     worktree = /some/where

is a configuration error, but probably I am missing a useful use case for such a configuration?

Show 5 quoted lines

> IMHO we should (probably after 1.5.3) change setup_git_directory_gently() 
> to call check_repository_format() in every return path, so that we 
> ascertain that the current repository is recent enough.  Because that 
> function now checks also if the repo is bare, and if it has a worktree 
> set, in addition to ensuring a valid repository.

Agreed; gently() is there primarily because some commands do not mind not having a git repository at all and if we do have a repository to work against we probably should do the same checks as setup_git_directory() would.