From: Shawn Pearce <spearce@spearce.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org, Theodore Tso <tytso@mit.edu>
Subject: Re: [PATCH 3/4] Automatically detect a bare git repository.
Date: Sun, 31 Dec 2006 00:26:06 -0500 [thread overview]
Message-ID: <20061231052606.GA5722@spearce.org> (raw)
In-Reply-To: <7vy7ook5xj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > This is in response to Theodore Tso's email asking why 'git log'
> > doesn't work in a bare repository. Now it does. :-)
>
> Does it?
It did in my testing. ;-)
> > @@ -160,36 +178,17 @@ const char *setup_git_directory_gently(int *nongit_ok)
> > * to do any discovery, but we still do repository
> > * validation.
> > */
> > - if (getenv(GIT_DIR_ENVIRONMENT)) {
> > - char path[PATH_MAX];
> > - int len = strlen(getenv(GIT_DIR_ENVIRONMENT));
> > - if (sizeof(path) - 40 < len)
> > + gitdirenv = getenv(GIT_DIR_ENVIRONMENT);
> > + if (gitdirenv) {
> > + if (PATH_MAX - 40 < strlen(gitdirenv))
> > die("'$%s' too big", GIT_DIR_ENVIRONMENT);
> > - memcpy(path, getenv(GIT_DIR_ENVIRONMENT), len);
> > -
> > - strcpy(path + len, "/refs");
> > - if (access(path, X_OK))
> > - goto bad_dir_environ;
> > - strcpy(path + len, "/HEAD");
> > - if (validate_symref(path))
> > - goto bad_dir_environ;
> > - if (getenv(DB_ENVIRONMENT)) {
> > - if (access(getenv(DB_ENVIRONMENT), X_OK))
> > - goto bad_dir_environ;
> > - }
> > - else {
> > - strcpy(path + len, "/objects");
> > - if (access(path, X_OK))
> > - goto bad_dir_environ;
> > - }
> > - return NULL;
> > - bad_dir_environ:
> > + if (is_git_directory(gitdirenv))
> > + return NULL;
> > if (nongit_ok) {
> > *nongit_ok = 1;
> > return NULL;
> > }
>
> I do not think this is correct.
>
> What happens when GIT_DIR is set, and nongit_ok is passed?
> Earlier code returned NULL after setting *nongit_ok so that the
> caller knows the environment points at a directory that is not
> yet a git repository control area.
The new code is correct, or at least does what the old code did.
If GIT_DIR is set we call is_git_directory(); if that returns 1
then the checks passed. In this case the old code returned NULL
and ignored nongit_ok. We do the same in the new code.
If GIT_DIR is set and we fail is_git_directory() then one of the
checks failed. In this case the old code jumped to bad_dir_env.
In the new code we don't return NULL and fall through into the if
nongit_ok testing, or into the die("Not a git repository").
> > @@ -197,11 +196,17 @@ const char *setup_git_directory_gently(int *nongit_ok)
> >
> > offset = len = strlen(cwd);
> > for (;;) {
> > - if (is_toplevel_directory())
> > + if (is_git_directory(".git"))
> > break;
> > chdir("..");
> > do {
> > if (!offset) {
> > + if (is_git_directory(cwd)) {
> > + if (chdir(cwd))
> > + die("Cannot come back to cwd");
> > + setenv(GIT_DIR_ENVIRONMENT, cwd, 1);
> > + return NULL;
> > + }
> > if (nongit_ok) {
> > if (chdir(cwd))
> > die("Cannot come back to cwd");
>
> I do not know what the new behaviour of this part of the code is
> trying to do. This is supposed to see if "." is the toplevel
> (equivalently, ".git" is the git_dir, in your implementation),
> otherwise chdir("..") repeatedly until it finds one, and the
> normal return condition is for the working directory of the
> process to be at the toplevel. So chdir(cwd) you introduced is
> obviously changing the behaviour.
No, its not.
We only bother to look to see if the original cwd (before we started
chdir("..")'ing up) is a git directory if we did not find one during
that chdir up loop. This means our current working directory is now
"/" but we found a valid repository in cwd.
In this case we chdir back to the repository directory before
returning back to the caller, as what's the point of being in "/"
when running in a bare repository? Probably better to be in the
repository directory itself.
One could argue that maybe we should run in "/", or in "/tmp" in
this case as there is no working directory associated with this
repository, but that argument is about the same as just saying we
go back into the now discovered GIT_DIR.
--
Shawn.
next prev parent reply other threads:[~2006-12-31 5:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3ffc8ddd9b500c2a34d2bd6ba147dc750d951bcd.1167539318.git.spearce@spearce.org>
2006-12-31 4:29 ` [PATCH 2/4] Replace "GIT_DIR" with GIT_DIR_ENVIRONMENT Shawn O. Pearce
2006-12-31 4:30 ` [PATCH 3/4] Automatically detect a bare git repository Shawn O. Pearce
2006-12-31 5:09 ` Junio C Hamano
2006-12-31 5:26 ` Shawn Pearce [this message]
2006-12-31 5:46 ` Junio C Hamano
2006-12-31 12:52 ` Theodore Tso
2007-01-01 21:01 ` Shawn O. Pearce
2006-12-31 17:54 ` Martin Waitz
2007-01-01 20:57 ` Shawn O. Pearce
2006-12-31 4:32 ` [RFC/PATCH 4/4] Disallow working directory commands in a bare repository Shawn O. Pearce
2006-12-31 5:33 ` Junio C Hamano
2006-12-31 6:11 ` Shawn O. Pearce
2006-12-31 8:01 ` Junio C Hamano
2006-12-31 12:49 ` Theodore Tso
2006-12-31 15:13 ` Johannes Schindelin
2006-12-31 19:19 ` Junio C Hamano
2007-01-02 21:42 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061231052606.GA5722@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).