"Horst H. von Brand" <vonbrand@xxxxxxxxxxxx> writes: > I tried this: > > mkdir xyz > cd xyz > git --git-dir=../xyz.git > # Initialized empty Git repository in ../xyz.git/ > echo Junk > file-a > git --git-dir=../xyz.git add . > # fatal: add cannot be used in a bare git directory > > I expected that "GIT_DIR is bare, over there, stuff is here" works the same > as "GIT_DIR is .git, right here among stuff". Sheesh, why didn't you speak out earlier while the discussion was on (I am not serious, git mailing list is still moving too fast for people to be always on top of)? Now, seriously. The "bare" topic introduced "is this repository bare?" check, which can say only "yes" or "no" for any given GIT_DIR. A heuristic is there but can be overriden with "core.bare" configuration. We allow certain things we usually do not allow in a repository without working tree (e.g. updating the branch pointed at with HEAD via "git-fetch"), and we forbid things that require a working tree in a bare repository (e.g. "git-checkout"). This "your bare repository is my repository with worktree elsewhere" was not something we considered during the "bare" discussion. If we wanted to allow that, the check needs to say "yes", "no", or "depends", and we need to allow both kinds of operations in a repository marked as the third kind. You said "I tried". Is this something you do in real life? This _is_ a regression, as we are checking something we did not check before and refusing to work in cases where we did. But I am not sure if reverting to lift the safety (for that matter, introducing the third "depends" alternative) is better than the latest behaviour. For one thing, you could (sometime before the "git add ." and do this only once) do: $ ln -s ../xyz.git .git and that would make all the future git operation work without the --git-dir parameter (or GIT_DIR environment) in xyz directory. An added benefit is that it would even allow git command to work from a subdirectory of xyz (specifying GIT_DIR or --git-dir means you are bypassing the discovery for the top of the working tree, so you have to always be at the top). Hmmmm. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html