{"thread":{"id":"6169","subject":"[PATCH 2/4] Replace \"GIT_DIR\" with GIT_DIR_ENVIRONMENT.","startedAt":"2006-12-31T04:29:11Z","lastAt":"2007-01-02T21:42:05Z","messageCount":17,"participants":["Shawn O. Pearce","Junio C Hamano","Shawn Pearce","Theodore Tso","Johannes Schindelin","Martin Waitz"],"isPatch":true,"patchVersion":1,"patchTotal":4},"messages":[{"id":"30545","messageId":"20061231042911.GB5823@spearce.org","threadId":"6169","inReplyTo":"3ffc8ddd9b500c2a34d2bd6ba147dc750d951bcd.1167539318.git.spearce@spearce.org","subject":"[PATCH 2/4] Replace \"GIT_DIR\" with GIT_DIR_ENVIRONMENT.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-31T04:29:11Z","receivedAt":"2006-12-31T04:29:11Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"We tend to use the nice constant GIT_DIR_ENVIRONMENT when we\nare referring to the \"GIT_DIR\" constant, but git.c didn't do\nso. Now it does.\n\nSigned-off-by: Shawn O. Pearce \n---\n git.c | 6 +++---\n 1 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/git.c b/git.c\nindex ec897dc..c82ca45 100644\n--- a/git.c\n+++ b/git.c\n@@ -63,14 +63,14 @@ static int handle_options(const char*** argv, int* argc)\n \t\t\t\tfprintf(stderr, \"No directory given for --git-dir.\\n\" );\n \t\t\t\tusage(git_usage_string);\n \t\t\t}\n-\t\t\tsetenv(\"GIT_DIR\", (*argv)[1], 1);\n+\t\t\tsetenv(GIT_DIR_ENVIRONMENT, (*argv)[1], 1);\n \t\t\t(*argv)++;\n \t\t\t(*argc)--;\n \t\t} else if (!strncmp(cmd, \"--git-dir=\", 10)) {\n-\t\t\tsetenv(\"GIT_DIR\", cmd + 10, 1);\n+\t\t\tsetenv(GIT_DIR_ENVIRONMENT, cmd + 10, 1);\n \t\t} else if (!strcmp(cmd, \"--bare\")) {\n \t\t\tstatic char git_dir[PATH_MAX+1];\n-\t\t\tsetenv(\"GIT_DIR\", getcwd(git_dir, sizeof(git_dir)), 1);\n+\t\t\tsetenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir, sizeof(git_dir)), 1);\n \t\t} else {\n \t\t\tfprintf(stderr, \"Unknown option: %s\\n\", cmd);\n \t\t\tusage(git_usage_string);\n-- \n1.5.0.rc0.g6bb1\n"},{"id":"30546","messageId":"20061231043019.GC5823@spearce.org","threadId":"6169","inReplyTo":"3ffc8ddd9b500c2a34d2bd6ba147dc750d951bcd.1167539318.git.spearce@spearce.org","subject":"[PATCH 3/4] Automatically detect a bare git repository.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-31T04:30:19Z","receivedAt":"2006-12-31T04:30:19Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Many users find it unfriendly that they can create a bare git\nrepository easily with `git clone --bare` but are then unable to\nrun simple commands like `git log` once they cd into that newly\ncreated bare repository. This occurs because we do not check to\nsee if the current working directory is a git repository.\n\nInstead of failing out with \"fatal: Not a git repository\" we should\ntry to automatically detect if the current working directory is\na bare repository and use that for GIT_DIR, and fail out only if\nthat doesn't appear to be true.\n\nWe test the current working directory only after we have tried\nsearching up the directory tree. This is to retain backwards\ncompatibility with our previous behavior on the off chance that\na user has a 'refs' and 'objects' subdirectories and a 'HEAD'\nfile that looks like a symref, all stored within a repository's\nassociated working directory.\n\nThis change also consolidates the validation logic between the case\nof GIT_DIR being supplied and GIT_DIR not being supplied, cleaning\nup the code.\n\nSigned-off-by: Shawn O. Pearce \n---\n\n This is in response to Theodore Tso's email asking why 'git log'\n doesn't work in a bare repository. Now it does. :-)\n\n setup.c | 73 +++++++++++++++++++++++++++++++++-----------------------------\n 1 files changed, 39 insertions(+), 34 deletions(-)\n\ndiff --git a/setup.c b/setup.c\nindex 2afdba4..2ae57f7 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -131,28 +131,46 @@ const char **get_pathspec(const char *prefix, const char **pathspec)\n }\n \n /*\n- * Test if it looks like we're at the top level git directory.\n+ * Test if it looks like we're at a git directory.\n * We want to see:\n *\n- * - either a .git/objects/ directory _or_ the proper\n+ * - either a objects/ directory _or_ the proper\n * GIT_OBJECT_DIRECTORY environment variable\n- * - a refs/ directory under \".git\"\n+ * - a refs/ directory\n * - either a HEAD symlink or a HEAD file that is formatted as\n * a proper \"ref:\".\n */\n-static int is_toplevel_directory(void)\n+static int is_git_directory(const char *suspect)\n {\n-\tif (access(\".git/refs/\", X_OK) ||\n-\t access(getenv(DB_ENVIRONMENT) ?\n-\t\t getenv(DB_ENVIRONMENT) : \".git/objects/\", X_OK) ||\n-\t validate_symref(\".git/HEAD\"))\n+\tchar path[PATH_MAX];\n+\tsize_t len = strlen(suspect);\n+\n+\tstrcpy(path, suspect);\n+\tif (getenv(DB_ENVIRONMENT)) {\n+\t\tif (access(getenv(DB_ENVIRONMENT), X_OK))\n+\t\t\treturn 0;\n+\t}\n+\telse {\n+\t\tstrcpy(path + len, \"/objects\");\n+\t\tif (access(path, X_OK))\n+\t\t\treturn 0;\n+\t}\n+\n+\tstrcpy(path + len, \"/refs\");\n+\tif (access(path, X_OK))\n \t\treturn 0;\n+\n+\tstrcpy(path + len, \"/HEAD\");\n+\tif (validate_symref(path))\n+\t\treturn 0;\n+\n \treturn 1;\n }\n \n const char *setup_git_directory_gently(int *nongit_ok)\n {\n \tstatic char cwd[PATH_MAX+1];\n+\tconst char *gitdirenv;\n \tint len, offset;\n \n \t/*\n@@ -160,36 +178,17 @@ const char *setup_git_directory_gently(int *nongit_ok)\n \t * to do any discovery, but we still do repository\n \t * validation.\n \t */\n-\tif (getenv(GIT_DIR_ENVIRONMENT)) {\n-\t\tchar path[PATH_MAX];\n-\t\tint len = strlen(getenv(GIT_DIR_ENVIRONMENT));\n-\t\tif (sizeof(path) - 40 < len)\n+\tgitdirenv = getenv(GIT_DIR_ENVIRONMENT);\n+\tif (gitdirenv) {\n+\t\tif (PATH_MAX - 40 < strlen(gitdirenv))\n \t\t\tdie(\"'$%s' too big\", GIT_DIR_ENVIRONMENT);\n-\t\tmemcpy(path, getenv(GIT_DIR_ENVIRONMENT), len);\n-\t\t\n-\t\tstrcpy(path + len, \"/refs\");\n-\t\tif (access(path, X_OK))\n-\t\t\tgoto bad_dir_environ;\n-\t\tstrcpy(path + len, \"/HEAD\");\n-\t\tif (validate_symref(path))\n-\t\t\tgoto bad_dir_environ;\n-\t\tif (getenv(DB_ENVIRONMENT)) {\n-\t\t\tif (access(getenv(DB_ENVIRONMENT), X_OK))\n-\t\t\t\tgoto bad_dir_environ;\n-\t\t}\n-\t\telse {\n-\t\t\tstrcpy(path + len, \"/objects\");\n-\t\t\tif (access(path, X_OK))\n-\t\t\t\tgoto bad_dir_environ;\n-\t\t}\n-\t\treturn NULL;\n-\tbad_dir_environ:\n+\t\tif (is_git_directory(gitdirenv))\n+\t\t\treturn NULL;\n \t\tif (nongit_ok) {\n \t\t\t*nongit_ok = 1;\n \t\t\treturn NULL;\n \t\t}\n-\t\tpath[len] = 0;\n-\t\tdie(\"Not a git repository: '%s'\", path);\n+\t\tdie(\"Not a git repository: '%s'\", gitdirenv);\n \t}\n \n \tif (!getcwd(cwd, sizeof(cwd)) || cwd[0] != '/')\n@@ -197,11 +196,17 @@ const char *setup_git_directory_gently(int *nongit_ok)\n \n \toffset = len = strlen(cwd);\n \tfor (;;) {\n-\t\tif (is_toplevel_directory())\n+\t\tif (is_git_directory(\".git\"))\n \t\t\tbreak;\n \t\tchdir(\"..\");\n \t\tdo {\n \t\t\tif (!offset) {\n+\t\t\t\tif (is_git_directory(cwd)) {\n+\t\t\t\t\tif (chdir(cwd))\n+\t\t\t\t\t\tdie(\"Cannot come back to cwd\");\n+\t\t\t\t\tsetenv(GIT_DIR_ENVIRONMENT, cwd, 1);\n+\t\t\t\t\treturn NULL;\n+\t\t\t\t}\n \t\t\t\tif (nongit_ok) {\n \t\t\t\t\tif (chdir(cwd))\n \t\t\t\t\t\tdie(\"Cannot come back to cwd\");\n-- \n1.5.0.rc0.g6bb1\n"},{"id":"30547","messageId":"20061231043238.GD5823@spearce.org","threadId":"6169","inReplyTo":"3ffc8ddd9b500c2a34d2bd6ba147dc750d951bcd.1167539318.git.spearce@spearce.org","subject":"[RFC/PATCH 4/4] Disallow working directory commands in a bare repository.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-31T04:32:38Z","receivedAt":"2006-12-31T04:32:38Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"If the user tries to run a porcelainish command which requires\na working directory in a bare repository they may get unexpected\nresults which are difficult to predict and may differ from command\nto command.\n\nInstead we should detect that the current repository is a bare\nrepository and refuse to run the command there, as there is no\nworking directory associated with it.\n\nSigned-off-by: Shawn O. Pearce \n---\n\n This is more of an RFC than an actual patch. I think its a good\n idea (clearly, as I spent the time to write it) but this may break\n users who explicitly set GIT_DIR to some path which doesn't end in\n \"/.git\" (e.g. GIT_DIR=$HOME/foo.git).\n\n I've tried to only alter poreclainish and leave plumbing alone,\n under the rationale that a different Porcelain may have different\n behavior with regards to GIT_DIR.\n\n git-am.sh | 1 +\n git-checkout.sh | 1 +\n git-clean.sh | 1 +\n git-commit.sh | 1 +\n git-merge.sh | 1 +\n git-pull.sh | 1 +\n git-rebase.sh | 1 +\n git-reset.sh | 1 +\n git-revert.sh | 1 +\n git-sh-setup.sh | 7 +++++++\n git.c | 11 +++++++----\n 11 files changed, 23 insertions(+), 4 deletions(-)\n\ndiff --git a/git-am.sh b/git-am.sh\nindex c3bbd78..8487e75 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -7,6 +7,7 @@ USAGE='[--signoff] [--dotest=] [--utf8] [--binary] [--3way]\n or, when resuming [--skip | --resolved]'\n . git-sh-setup\n set_reflog_action am\n+require_not_bare\n \n git var GIT_COMMITTER_IDENT >/dev/null || exit\n \ndiff --git a/git-checkout.sh b/git-checkout.sh\nindex 92ec069..b2d2dfa 100755\n--- a/git-checkout.sh\n+++ b/git-checkout.sh\n@@ -3,6 +3,7 @@\n USAGE='[-f] [-b ] [-m] [] [...]'\n SUBDIRECTORY_OK=Sometimes\n . git-sh-setup\n+require_not_bare\n \n old_name=HEAD\n old=$(git-rev-parse --verify $old_name 2>/dev/null)\ndiff --git a/git-clean.sh b/git-clean.sh\nindex 3834323..79c5bad 100755\n--- a/git-clean.sh\n+++ b/git-clean.sh\n@@ -14,6 +14,7 @@ When optional ... arguments are given, the paths\n affected are further limited to those that match them.'\n SUBDIRECTORY_OK=Yes\n . git-sh-setup\n+require_not_bare\n \n ignored=\n ignoredonly=\ndiff --git a/git-commit.sh b/git-commit.sh\nindex 6bce41a..813f41c 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -6,6 +6,7 @@\n USAGE='[-a] [-s] [-v] [--no-verify] [-m | -F | (-C|-c) ] [-u] [--amend] [-e] [--author ] [[-i | -o] ...]'\n SUBDIRECTORY_OK=Yes\n . git-sh-setup\n+require_not_bare\n \n git-rev-parse --verify HEAD >/dev/null 2>&1 || initial_commit=t\n branch=$(GIT_DIR=\"$GIT_DIR\" git-symbolic-ref HEAD)\ndiff --git a/git-merge.sh b/git-merge.sh\nindex ba42260..d91ff0d 100755\n--- a/git-merge.sh\n+++ b/git-merge.sh\n@@ -7,6 +7,7 @@ USAGE='[-n] [--no-commit] [--squash] [-s ] [-m=] option & USE_PAGER)\n \t\t\tsetup_pager();\n+\t\tif (p->option & NOT_BARE && is_bare_git_dir(get_git_dir()))\n+\t\t\tdie(\"%s cannot be used in a pare git directory\", cmd);\n \t\ttrace_argv_printf(argv, argc, \"trace: built-in: git\");\n \n \t\texit(p->fn(argc, argv, prefix));\n-- \n1.5.0.rc0.g6bb1\n"},{"id":"30550","messageId":"7vy7ook5xj.fsf@assigned-by-dhcp.cox.net","threadId":"6169","inReplyTo":"20061231043019.GC5823@spearce.org","subject":"Re: [PATCH 3/4] Automatically detect a bare git repository.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-31T05:09:12Z","receivedAt":"2006-12-31T05:09:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> This is in response to Theodore Tso's email asking why 'git log'\n> doesn't work in a bare repository. Now it does. :-)\n\nDoes it?\n\n> +static int is_git_directory(const char *suspect)\n> {\n> +\tchar path[PATH_MAX];\n> ...\n> +\n> \treturn 1;\n> }\n\nI think this is a good refactoring.\n\n> @@ -160,36 +178,17 @@ const char *setup_git_directory_gently(int *nongit_ok)\n> \t * to do any discovery, but we still do repository\n> \t * validation.\n> \t */\n> -\tif (getenv(GIT_DIR_ENVIRONMENT)) {\n> -\t\tchar path[PATH_MAX];\n> -\t\tint len = strlen(getenv(GIT_DIR_ENVIRONMENT));\n> -\t\tif (sizeof(path) - 40 < len)\n> +\tgitdirenv = getenv(GIT_DIR_ENVIRONMENT);\n> +\tif (gitdirenv) {\n> +\t\tif (PATH_MAX - 40 < strlen(gitdirenv))\n> \t\t\tdie(\"'$%s' too big\", GIT_DIR_ENVIRONMENT);\n> -\t\tmemcpy(path, getenv(GIT_DIR_ENVIRONMENT), len);\n> -\t\t\n> -\t\tstrcpy(path + len, \"/refs\");\n> -\t\tif (access(path, X_OK))\n> -\t\t\tgoto bad_dir_environ;\n> -\t\tstrcpy(path + len, \"/HEAD\");\n> -\t\tif (validate_symref(path))\n> -\t\t\tgoto bad_dir_environ;\n> -\t\tif (getenv(DB_ENVIRONMENT)) {\n> -\t\t\tif (access(getenv(DB_ENVIRONMENT), X_OK))\n> -\t\t\t\tgoto bad_dir_environ;\n> -\t\t}\n> -\t\telse {\n> -\t\t\tstrcpy(path + len, \"/objects\");\n> -\t\t\tif (access(path, X_OK))\n> -\t\t\t\tgoto bad_dir_environ;\n> -\t\t}\n> -\t\treturn NULL;\n> -\tbad_dir_environ:\n> +\t\tif (is_git_directory(gitdirenv))\n> +\t\t\treturn NULL;\n> \t\tif (nongit_ok) {\n> \t\t\t*nongit_ok = 1;\n> \t\t\treturn NULL;\n> \t\t}\n\nI do not think this is correct.\n\nWhat happens when GIT_DIR is set, and nongit_ok is passed?\nEarlier code returned NULL after setting *nongit_ok so that the\ncaller knows the environment points at a directory that is not\nyet a git repository control area.\n\n> @@ -197,11 +196,17 @@ const char *setup_git_directory_gently(int *nongit_ok)\n> \n> \toffset = len = strlen(cwd);\n> \tfor (;;) {\n> -\t\tif (is_toplevel_directory())\n> +\t\tif (is_git_directory(\".git\"))\n> \t\t\tbreak;\n> \t\tchdir(\"..\");\n> \t\tdo {\n> \t\t\tif (!offset) {\n> +\t\t\t\tif (is_git_directory(cwd)) {\n> +\t\t\t\t\tif (chdir(cwd))\n> +\t\t\t\t\t\tdie(\"Cannot come back to cwd\");\n> +\t\t\t\t\tsetenv(GIT_DIR_ENVIRONMENT, cwd, 1);\n> +\t\t\t\t\treturn NULL;\n> +\t\t\t\t}\n> \t\t\t\tif (nongit_ok) {\n> \t\t\t\t\tif (chdir(cwd))\n> \t\t\t\t\t\tdie(\"Cannot come back to cwd\");\n\nI do not know what the new behaviour of this part of the code is\ntrying to do. This is supposed to see if \".\" is the toplevel\n(equivalently, \".git\" is the git_dir, in your implementation),\notherwise chdir(\"..\") repeatedly until it finds one, and the\nnormal return condition is for the working directory of the\nprocess to be at the toplevel. So chdir(cwd) you introduced is\nobviously changing the behaviour.\n\nThe existing chdir(cwd) is for an error return -- when there was\nno directory that has \".git\" even when you went all the way up\nto the root level, we give up and come back to where we started,\nonly when the caller suspected that there was no git directory\nand is prepared to handle that case, which is signalled by us\nstoring 1 to *nongit_ok.\n"},{"id":"30551","messageId":"20061231052606.GA5722@spearce.org","threadId":"6169","inReplyTo":"7vy7ook5xj.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 3/4] Automatically detect a bare git repository.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-31T05:26:06Z","receivedAt":"2006-12-31T05:26:06Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> \n> > This is in response to Theodore Tso's email asking why 'git log'\n> > doesn't work in a bare repository. Now it does. :-)\n> \n> Does it?\n\nIt did in my testing. ;-)\n \n> > @@ -160,36 +178,17 @@ const char *setup_git_directory_gently(int *nongit_ok)\n> > \t * to do any discovery, but we still do repository\n> > \t * validation.\n> > \t */\n> > -\tif (getenv(GIT_DIR_ENVIRONMENT)) {\n> > -\t\tchar path[PATH_MAX];\n> > -\t\tint len = strlen(getenv(GIT_DIR_ENVIRONMENT));\n> > -\t\tif (sizeof(path) - 40 < len)\n> > +\tgitdirenv = getenv(GIT_DIR_ENVIRONMENT);\n> > +\tif (gitdirenv) {\n> > +\t\tif (PATH_MAX - 40 < strlen(gitdirenv))\n> > \t\t\tdie(\"'$%s' too big\", GIT_DIR_ENVIRONMENT);\n> > -\t\tmemcpy(path, getenv(GIT_DIR_ENVIRONMENT), len);\n> > -\t\t\n> > -\t\tstrcpy(path + len, \"/refs\");\n> > -\t\tif (access(path, X_OK))\n> > -\t\t\tgoto bad_dir_environ;\n> > -\t\tstrcpy(path + len, \"/HEAD\");\n> > -\t\tif (validate_symref(path))\n> > -\t\t\tgoto bad_dir_environ;\n> > -\t\tif (getenv(DB_ENVIRONMENT)) {\n> > -\t\t\tif (access(getenv(DB_ENVIRONMENT), X_OK))\n> > -\t\t\t\tgoto bad_dir_environ;\n> > -\t\t}\n> > -\t\telse {\n> > -\t\t\tstrcpy(path + len, \"/objects\");\n> > -\t\t\tif (access(path, X_OK))\n> > -\t\t\t\tgoto bad_dir_environ;\n> > -\t\t}\n> > -\t\treturn NULL;\n> > -\tbad_dir_environ:\n> > +\t\tif (is_git_directory(gitdirenv))\n> > +\t\t\treturn NULL;\n> > \t\tif (nongit_ok) {\n> > \t\t\t*nongit_ok = 1;\n> > \t\t\treturn NULL;\n> > \t\t}\n> \n> I do not think this is correct.\n>\n> What happens when GIT_DIR is set, and nongit_ok is passed?\n> Earlier code returned NULL after setting *nongit_ok so that the\n> caller knows the environment points at a directory that is not\n> yet a git repository control area.\n\nThe new code is correct, or at least does what the old code did.\n\nIf GIT_DIR is set we call is_git_directory(); if that returns 1\nthen the checks passed. In this case the old code returned NULL\nand ignored nongit_ok. We do the same in the new code.\n\nIf GIT_DIR is set and we fail is_git_directory() then one of the\nchecks failed. In this case the old code jumped to bad_dir_env.\nIn the new code we don't return NULL and fall through into the if\nnongit_ok testing, or into the die(\"Not a git repository\").\n \n> > @@ -197,11 +196,17 @@ const char *setup_git_directory_gently(int *nongit_ok)\n> > \n> > \toffset = len = strlen(cwd);\n> > \tfor (;;) {\n> > -\t\tif (is_toplevel_directory())\n> > +\t\tif (is_git_directory(\".git\"))\n> > \t\t\tbreak;\n> > \t\tchdir(\"..\");\n> > \t\tdo {\n> > \t\t\tif (!offset) {\n> > +\t\t\t\tif (is_git_directory(cwd)) {\n> > +\t\t\t\t\tif (chdir(cwd))\n> > +\t\t\t\t\t\tdie(\"Cannot come back to cwd\");\n> > +\t\t\t\t\tsetenv(GIT_DIR_ENVIRONMENT, cwd, 1);\n> > +\t\t\t\t\treturn NULL;\n> > +\t\t\t\t}\n> > \t\t\t\tif (nongit_ok) {\n> > \t\t\t\t\tif (chdir(cwd))\n> > \t\t\t\t\t\tdie(\"Cannot come back to cwd\");\n> \n> I do not know what the new behaviour of this part of the code is\n> trying to do. This is supposed to see if \".\" is the toplevel\n> (equivalently, \".git\" is the git_dir, in your implementation),\n> otherwise chdir(\"..\") repeatedly until it finds one, and the\n> normal return condition is for the working directory of the\n> process to be at the toplevel. So chdir(cwd) you introduced is\n> obviously changing the behaviour.\n\nNo, its not.\n\nWe only bother to look to see if the original cwd (before we started\nchdir(\"..\")'ing up) is a git directory if we did not find one during\nthat chdir up loop. This means our current working directory is now\n\"/\" but we found a valid repository in cwd.\n\nIn this case we chdir back to the repository directory before\nreturning back to the caller, as what's the point of being in \"/\"\nwhen running in a bare repository? Probably better to be in the\nrepository directory itself.\n\nOne could argue that maybe we should run in \"/\", or in \"/tmp\" in\nthis case as there is no working directory associated with this\nrepository, but that argument is about the same as just saying we\ngo back into the now discovered GIT_DIR.\n\n-- \nShawn.\n"},{"id":"30552","messageId":"7virfsk4sd.fsf@assigned-by-dhcp.cox.net","threadId":"6169","inReplyTo":"20061231043238.GD5823@spearce.org","subject":"Re: [RFC/PATCH 4/4] Disallow working directory commands in a bare repository.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-31T05:33:54Z","receivedAt":"2006-12-31T05:33:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I think the intent is good.\n\nBut execution has room for improvement, and it is not your\nfault. The shell script version of require_not_bare is as\nfragile as is_bare_git_dir(), which I already do not like, and I\nthink if we are going to use is_bare_git_dir() more, I think we\nwould want to have something a bit more robust.\n\nIf we could outlaw $GIT_DIR/index in a bare repository, then\nlack of $GIT_DIR/index combined with nonexistence of ref that\nis pointed at by $GIT_DIR/HEAD could become a good indication\nthat the repository is bare (\"the current branch unborn\" check\nis needed not to mistake a repository before the initial commit\nas a bare one).\n\nAlas, many public repositories you would see (e.g. check\nkernel.org) have been primed with rsync of .git/ from\ndeveloper's working repository and have leftover index that is\notherwise unused. Because of this heavy historical baggage, I\nsuspect that it is rather hard to convince people to allow us to\nuse this technique.\n\nWhen you have $GIT_DIR in your environment, no working-tree\ncommand is expected to work unless you are at the toplevel of\nthe working-tree. In the past, people talked about their\nworkflows using more than one working trees that are associated\nwith a single $GIT_DIR and that is certainly supposed to work.\nBut I wonder how widely such a set-up is employed in practice.\nIf we outlawed working-tree commands when $GIT_DIR environment\nexists, how much hurt are we talking about, I wonder.\n\nAnother thing to think about is if we are happy with the above\nrestriction that makes environment $GIT_DIR to imply you are\nalways working at the toplevel. Maybe it could be a good idea\nto kill this bird as well by introducing $GIT_WORKTREE_TOP\nenvironment variable. Presence of it obviously means we are not\nin a bare repository, but at the same time it would allow us to\nteach setup_git_directory_gentry() to cd up to that directory to\nmake the commands behave as expected.\n"},{"id":"30555","messageId":"7v8xgok46s.fsf@assigned-by-dhcp.cox.net","threadId":"6169","inReplyTo":"20061231052606.GA5722@spearce.org","subject":"Re: [PATCH 3/4] Automatically detect a bare git repository.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-31T05:46:51Z","receivedAt":"2006-12-31T05:46:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> Junio C Hamano wrote:\n> ...\n>\n> If GIT_DIR is set we call is_git_directory(); if that returns 1\n> then the checks passed. In this case the old code returned NULL\n> and ignored nongit_ok. We do the same in the new code.\n\nOk.\n\n>> > \tfor (;;) {\n>> > -\t\tif (is_toplevel_directory())\n>> > +\t\tif (is_git_directory(\".git\"))\n>> > \t\t\tbreak;\n>> > \t\tchdir(\"..\");\n>> > \t\tdo {\n>> > \t\t\tif (!offset) {\n>> > +\t\t\t\tif (is_git_directory(cwd)) {\n>> > +\t\t\t\t\tif (chdir(cwd))\n>> > +\t\t\t\t\t\tdie(\"Cannot come back to cwd\");\n>> > +\t\t\t\t\tsetenv(GIT_DIR_ENVIRONMENT, cwd, 1);\n>> > +\t\t\t\t\treturn NULL;\n>> > +\t\t\t\t}\n>> > \t\t\t\tif (nongit_ok) {\n>> > \t\t\t\t\tif (chdir(cwd))\n>> > \t\t\t\t\t\tdie(\"Cannot come back to cwd\");\n>> \n>> I do not know what the new behaviour of this part of the code is\n>> trying to do. This is supposed to see if \".\" is the toplevel\n>> (equivalently, \".git\" is the git_dir, in your implementation),\n>> otherwise chdir(\"..\") repeatedly until it finds one, and the\n>> normal return condition is for the working directory of the\n>> process to be at the toplevel. So chdir(cwd) you introduced is\n>> obviously changing the behaviour.\n>\n> No, its not.\n\nAh, \"changing the behaviour\" is the correct thing to do, because\nthe code is now allowing a new fallback to allow the original\ndirectory to be a bare git repository, and the new chdir/setenv\nmakes perfect sense. Thanks for clarification.\n\nFor a short time I wondered if this should be a fallback\nposition, or we might want to make this the very first thing to\ncheck, but I think adding this as the last ditch fallback\nposition as you did is much safer than making it the first thing\nto check.\n\nThanks.\n"},{"id":"30560","messageId":"20061231061122.GB6106@spearce.org","threadId":"6169","inReplyTo":"7virfsk4sd.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC/PATCH 4/4] Disallow working directory commands in a bare repository.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-31T06:11:22Z","receivedAt":"2006-12-31T06:11:22Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> But execution has room for improvement, and it is not your\n> fault. The shell script version of require_not_bare is as\n> fragile as is_bare_git_dir(), which I already do not like, and I\n> think if we are going to use is_bare_git_dir() more, I think we\n> would want to have something a bit more robust.\n\nAgreed. But as you point out...\n \n> If we could outlaw $GIT_DIR/index in a bare repository, then\n> lack of $GIT_DIR/index combined with nonexistence of ref that\n> is pointed at by $GIT_DIR/HEAD could become a good indication\n> that the repository is bare (\"the current branch unborn\" check\n> is needed not to mistake a repository before the initial commit\n> as a bare one).\n> \n> Alas, many public repositories you would see (e.g. check\n> kernel.org) have been primed with rsync of .git/ from\n> developer's working repository and have leftover index that is\n> otherwise unused. Because of this heavy historical baggage, I\n> suspect that it is rather hard to convince people to allow us to\n> use this technique.\n\nI almost coded the require_not_bare() to look for $GIT_DIR/index\nbut didn't for the reasons you point out above. It is too bad that\nwe didn't enforce the existance of the index file better in the past.\n\n> When you have $GIT_DIR in your environment, no working-tree\n> command is expected to work unless you are at the toplevel of\n> the working-tree. In the past, people talked about their\n> workflows using more than one working trees that are associated\n> with a single $GIT_DIR \n\nWhat happens with $GIT_DIR/index in this case? Or $GIT_DIR/HEAD?\nIts insane because both need to be affiliated with the working\ndirectory, yet there's only the one set. Sure the user could also\narrange for $GIT_INDEX_FILE to be set based on the working directory,\nbut what about $GIT_DIR/HEAD? There is no equivilant.\n\n> and that is certainly supposed to work.\n> But I wonder how widely such a set-up is employed in practice.\n> If we outlawed working-tree commands when $GIT_DIR environment\n> exists, how much hurt are we talking about, I wonder.\n\nI wouldn't be hurt, but I don't call Porcelain-ish unless I'm\nentering commands directly on the command line, and I never set\nGIT_DIR except in scripts, and even then its very rare and is more\nto point at a bare repository than one with a working directory.\nI suspect that probably isn't true for everyone.\n\n> Another thing to think about is if we are happy with the above\n> restriction that makes environment $GIT_DIR to imply you are\n> always working at the toplevel. Maybe it could be a good idea\n> to kill this bird as well by introducing $GIT_WORKTREE_TOP\n> environment variable. Presence of it obviously means we are not\n> in a bare repository, but at the same time it would allow us to\n> teach setup_git_directory_gentry() to cd up to that directory to\n> make the commands behave as expected.\n\nI'm not sure what value that environment variable offers here.\n\nUsers who set GIT_DIR but don't today set GIT_WORKTREE_TOP are\nbroken by this change because its not set and we assume its bare.\nSo they need to also set this environment variable. But that\nis probably going to be annoying for those users as I doubt they\nare setting GIT_DIR on a per-directory basis.\n\nWhy not just tell these users to setup the working directories with\nlocal .git directories and not use GIT_DIR?\n\n-- \nShawn.\n"},{"id":"30568","messageId":"7vk608fq9u.fsf@assigned-by-dhcp.cox.net","threadId":"6169","inReplyTo":"20061231061122.GB6106@spearce.org","subject":"Re: [RFC/PATCH 4/4] Disallow working directory commands in a bare repository.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-31T08:01:01Z","receivedAt":"2006-12-31T08:01:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Agreed. But as you point out...\n> \n>> If we could outlaw $GIT_DIR/index in a bare repository, then\n>> ...\n>> Alas, many public repositories you would see (e.g. check\n>> kernel.org) have been primed with rsync of .git/ from\n>> developer's working repository and have leftover index that is\n>> otherwise unused. Because of this heavy historical baggage, I\n>> suspect that it is rather hard to convince people to allow us to\n>> use this technique.\n>\n> I almost coded the require_not_bare() to look for $GIT_DIR/index\n> but didn't for the reasons you point out above. It is too bad that\n> we didn't enforce the existance of the index file better in the past.\n\nThis, and this,...\n\n>> ...\n>> If we outlawed working-tree commands when $GIT_DIR environment\n>> exists, how much hurt are we talking about, I wonder.\n>\n> I wouldn't be hurt, but I don't call Porcelain-ish unless I'm\n> entering commands directly on the command line, and I never set\n> GIT_DIR except in scripts, and even then its very rare and is more\n> to point at a bare repository than one with a working directory.\n> I suspect that probably isn't true for everyone.\n> ...\n> Why not just tell these users to setup the working directories with\n> local .git directories and not use GIT_DIR?\n\nsuggest that we might want to bite the bullet and declare that\nthese things are not supported anymore in v1.5.0.\n\nSo far, especially after fixing the i18n issue in response to\nqgit problem report, I do not think we have any serious backward\nincompatibility that the users cannot opt out of that we need to\nmention in v1.5.0 announcement. Even not the incompatibilities\nthe 'old news' section talks about are.\n\nI think an index file in a bare repository is not what the user\nwanted to have because it was useful, but is left there because\nit does not hurt. So in that sense, I do not think we need to\nask users' permission to do this change, as long as we make sure\nwe give them enough advance warning.\n\nI do not offhand think of a valid workflow that relies on\nsetting GIT_DIR in the environment and being able to run\nworking-tree commands, that cannot be worked around if we declar\nthat GIT_DIR is for our internal use (and no, naming the\ndirectory other people call .git to .svn does not count as a\nvalid workflow), but I think this may be a bit more serious\nchange than the index file one.\n\nComments?\n"},{"id":"30577","messageId":"20061231124921.GA14286@thunk.org","threadId":"6169","inReplyTo":"7vk608fq9u.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC/PATCH 4/4] Disallow working directory commands in a bare repository.","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2006-12-31T12:49:21Z","receivedAt":"2006-12-31T12:49:21Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Dec 31, 2006 at 12:01:01AM -0800, Junio C Hamano wrote:\n> > Why not just tell these users to setup the working directories with\n> > local .git directories and not use GIT_DIR?\n> \n> suggest that we might want to bite the bullet and declare that\n> these things are not supported anymore in v1.5.0.\n\nWhile we're talking about potentially deprecating GIT_DIR for users,\nout of curiosity, what valid workflows would cause users to want to\nuse GIT_INDEX_FILE and GIT_OBJECT_DIRECTORY? Seems like they would\ncause more confusion and support problems than anything else. \n\n\t\t\t\t\t\t- Ted\n"},{"id":"30578","messageId":"20061231125205.GB14286@thunk.org","threadId":"6169","inReplyTo":"20061231043019.GC5823@spearce.org","subject":"Re: [PATCH 3/4] Automatically detect a bare git repository.","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2006-12-31T12:52:05Z","receivedAt":"2006-12-31T12:52:05Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sat, Dec 30, 2006 at 11:30:19PM -0500, Shawn O. Pearce wrote:\n> Many users find it unfriendly that they can create a bare git\n> repository easily with `git clone --bare` but are then unable to\n> run simple commands like `git log` once they cd into that newly\n> created bare repository. This occurs because we do not check to\n> see if the current working directory is a git repository.\n\nThanks for coding this up! \n\nIf you do this, does this mean that we can also eliminate the global\nvariable --bare, since git will be able to figure out we're in a bare\nrepository all by itself?\n\n\t\t\t\t\t\t- Ted\n"},{"id":"30582","messageId":"Pine.LNX.4.63.0612311606330.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6169","inReplyTo":"20061231124921.GA14286@thunk.org","subject":"Re: [RFC/PATCH 4/4] Disallow working directory commands in a bare repository.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-31T15:13:10Z","receivedAt":"2006-12-31T15:13:10Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 31 Dec 2006, Theodore Tso wrote:\n\n> On Sun, Dec 31, 2006 at 12:01:01AM -0800, Junio C Hamano wrote:\n> > > Why not just tell these users to setup the working directories with\n> > > local .git directories and not use GIT_DIR?\n> > \n> > suggest that we might want to bite the bullet and declare that\n> > these things are not supported anymore in v1.5.0.\n> \n> While we're talking about potentially deprecating GIT_DIR for users,\n> out of curiosity, what valid workflows would cause users to want to\n> use GIT_INDEX_FILE and GIT_OBJECT_DIRECTORY? Seems like they would\n> cause more confusion and support problems than anything else. \n\nEasy, guys.\n\nIt is a valid -- indeed, useful -- thing to be able to script nice \nhelpers. For example, in one project I track tar balls. So, I wrote a \nscript which will unpack the tar ball in a directory, build a new index \nfrom it, and commit the corresponding tree on top of the tracking branch. \nThis setup relies _heavily_ on being able to redirect GIT_INDEX_FILE and \nGIT_DIR.\n\nSo, these things are _useful_. Please don't break them.\n\nAs for the presence of \"index\" in a bare repo: I think this is not a \nproblem, _as long_ as things continue to work as before, i.e.\n\n\t$ GIT_DIR=$(pwd) git log\n\nand\n\n\t$ git --bare log\n\ndo _not_ complain if \"index\" is there. Now, if somebody starts git in a \nbare repo, where \"index\" is present, it could die with a helpful message \nlike\n\n\tIt seems that this is a bare git repository, but there is an index \n\tfile present, which contradicts that assumption. If the repository\n\tis indeed bare, please remove the index file.\n\nCiao,\nDscho\n"},{"id":"30586","messageId":"20061231175407.GC6115@admingilde.org","threadId":"6169","inReplyTo":"20061231043019.GC5823@spearce.org","subject":"Re: [PATCH 3/4] Automatically detect a bare git repository.","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-12-31T17:54:07Z","receivedAt":"2006-12-31T17:54:07Z","isPatch":true,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Sat, Dec 30, 2006 at 11:30:19PM -0500, Shawn O. Pearce wrote:\n> We test the current working directory only after we have tried\n> searching up the directory tree. This is to retain backwards\n> compatibility with our previous behavior on the off chance that\n> a user has a 'refs' and 'objects' subdirectories and a 'HEAD'\n> file that looks like a symref, all stored within a repository's\n> associated working directory.\n\nHmm, I have my dot files under GIT control so I can't use this mechanism\nto use bare GIT repositories under ~/git/*.git.\n\nPerhaps we should test the current directory first, but check that it\nends in .git?\n\n-- \nMartin Waitz\n"},{"id":"30587","messageId":"7vr6ufeuvf.fsf@assigned-by-dhcp.cox.net","threadId":"6169","inReplyTo":"Pine.LNX.4.63.0612311606330.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC/PATCH 4/4] Disallow working directory commands in a bare repository.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-31T19:19:16Z","receivedAt":"2006-12-31T19:19:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> While we're talking about potentially deprecating GIT_DIR for users,\n>> out of curiosity, what valid workflows would cause users to want to\n>> use GIT_INDEX_FILE and GIT_OBJECT_DIRECTORY? Seems like they would\n>> cause more confusion and support problems than anything else. \n>\n> Easy, guys.\n>\n> It is a valid -- indeed, useful -- thing to be able to script nice \n> helpers. For example, in one project I track tar balls. So, I wrote a \n> script which will unpack the tar ball in a directory, build a new index \n> from it, and commit the corresponding tree on top of the tracking branch. \n> This setup relies _heavily_ on being able to redirect GIT_INDEX_FILE and \n> GIT_DIR.\n\nI do agree INDEX_FILE and OBJECT_DIRECTORY are handy things for\nthe user to muck around. What I am not sure about is GIT_DIR,\nin the sense that I suspect it is not such a pain to do without\nfor such a script.\n\n> ... Now, if somebody starts git in a \n> bare repo, where \"index\" is present, it could die with a helpful message \n> like\n>\n> \tIt seems that this is a bare git repository, but there is an index \n> \tfile present, which contradicts that assumption. If the repository\n> \tis indeed bare, please remove the index file.\n\nThat is probably worse. \n\n * there is no reason for non working-tree operations such as\n git-log to fail when you go to a bare repository (or for that\n matter .git in a repository with a working-tree). we should\n not have to error out nor remove the index we will not use.\n\n * if you did the above in response to a misguided 'git\n checkout' in a bare repository, the next error message the\n user will get will be 'huh? you are in a bare repository,\n bozo'.\n\nSo I do not think the helpful message should even be necessary.\n"},{"id":"30624","messageId":"20070101205743.GA26821@spearce.org","threadId":"6169","inReplyTo":"20061231175407.GC6115@admingilde.org","subject":"Re: [PATCH 3/4] Automatically detect a bare git repository.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-01T20:57:43Z","receivedAt":"2007-01-01T20:57:43Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Martin Waitz wrote:\n> On Sat, Dec 30, 2006 at 11:30:19PM -0500, Shawn O. Pearce wrote:\n> > We test the current working directory only after we have tried\n> > searching up the directory tree. This is to retain backwards\n> > compatibility with our previous behavior on the off chance that\n> > a user has a 'refs' and 'objects' subdirectories and a 'HEAD'\n> > file that looks like a symref, all stored within a repository's\n> > associated working directory.\n> \n> Hmm, I have my dot files under GIT control so I can't use this mechanism\n> to use bare GIT repositories under ~/git/*.git.\n\nWhoops. I assume you have your .gitignore populated with the other\nfiles/directories in your home directory that shouldn't be under\nGit control?\n \n> Perhaps we should test the current directory first, but check that it\n> ends in .git?\n\nJunio already stated why that may not be a good idea. My original\nversion of the patch did check the current directory first, but it\ncould match a working directory which isn't really a Git repository\nbut just looks sort of like one.\n\nThat wouldn't be backwards compatible, so I moved the current\ndirectory check to just before failure. That version is the one\nthat I submitted, and that Junio accepted...\n\n-- \nShawn.\n"},{"id":"30625","messageId":"20070101210103.GB26821@spearce.org","threadId":"6169","inReplyTo":"20061231125205.GB14286@thunk.org","subject":"Re: [PATCH 3/4] Automatically detect a bare git repository.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-01T21:01:03Z","receivedAt":"2007-01-01T21:01:03Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Theodore Tso wrote:\n> On Sat, Dec 30, 2006 at 11:30:19PM -0500, Shawn O. Pearce wrote:\n> > Many users find it unfriendly that they can create a bare git\n> > repository easily with `git clone --bare` but are then unable to\n> > run simple commands like `git log` once they cd into that newly\n> > created bare repository. This occurs because we do not check to\n> > see if the current working directory is a git repository.\n> \n> Thanks for coding this up! \n> \n> If you do this, does this mean that we can also eliminate the global\n> variable --bare, since git will be able to figure out we're in a bare\n> repository all by itself?\n\nProbably not. `git --bare foo` is a Poreclain-ish level option\nwhich has been supported for several versions. Removing it may\ncause pain for users to retrain their fingers to just ignore it.\n\nBesides `git --bare` can be used in cases where the bare Git\nrepository is actually located within another repository's working\ndirectory and the automatic detection is picking up the other\nrepository's metadata and not the bare repository's metadata.\n\nSo I think --bare is still here to stay for a while. The new\nautomatic detection just offers slightly less surprise for users.\n\n-- \nShawn.\n"},{"id":"30705","messageId":"Pine.LNX.4.63.0701022236520.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6169","inReplyTo":"7vr6ufeuvf.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC/PATCH 4/4] Disallow working directory commands in a bare repository.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-02T21:42:05Z","receivedAt":"2007-01-02T21:42:05Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 31 Dec 2006, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> While we're talking about potentially deprecating GIT_DIR for users,\n> >> out of curiosity, what valid workflows would cause users to want to\n> >> use GIT_INDEX_FILE and GIT_OBJECT_DIRECTORY? Seems like they would\n> >> cause more confusion and support problems than anything else. \n> >\n> > Easy, guys.\n> >\n> > It is a valid -- indeed, useful -- thing to be able to script nice \n> > helpers. For example, in one project I track tar balls. So, I wrote a \n> > script which will unpack the tar ball in a directory, build a new index \n> > from it, and commit the corresponding tree on top of the tracking branch. \n> > This setup relies _heavily_ on being able to redirect GIT_INDEX_FILE and \n> > GIT_DIR.\n> \n> I do agree INDEX_FILE and OBJECT_DIRECTORY are handy things for\n> the user to muck around. What I am not sure about is GIT_DIR,\n> in the sense that I suspect it is not such a pain to do without\n> for such a script.\n\nUhm. In the example I illustrated, I need to set GIT_DIR, because I want \nto commit a new version into a branch of my current repository, but \nwithout touching the working tree and the index.\n\nThus, I have to create a temporary directory, unpack the new \n(upstream) version, set GIT_DIR _and_ GIT_INDEX_FILE, do a write-tree and \na commit-tree with some automatic message, and then update the ref. Yes, I \ncould separate the steps, but why make it harder than it needs be?\n\n> > ... Now, if somebody starts git in a \n> > bare repo, where \"index\" is present, it could die with a helpful message \n> > like\n> >\n> > \tIt seems that this is a bare git repository, but there is an index \n> > \tfile present, which contradicts that assumption. If the repository\n> > \tis indeed bare, please remove the index file.\n> \n> That is probably worse. \n> \n> * there is no reason for non working-tree operations such as\n> git-log to fail when you go to a bare repository (or for that\n> matter .git in a repository with a working-tree). we should\n> not have to error out nor remove the index we will not use.\n> \n> * if you did the above in response to a misguided 'git\n> checkout' in a bare repository, the next error message the\n> user will get will be 'huh? you are in a bare repository,\n> bozo'.\n> \n> So I do not think the helpful message should even be necessary.\n\nYeah, I meant this message only to appear when you call a program which \nneeds a working directory. But I agree that this is probably stupid.\n\nCiao,\nDscho\n"}]}