From: Jeff King <peff@peff.net>
To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Cc: Daniel Convissor <danielc@analysisandsolutions.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: hitting home directory's parent
Date: Tue, 25 Aug 2009 00:42:36 -0400 [thread overview]
Message-ID: <20090825044236.GA13738@coredump.intra.peff.net> (raw)
In-Reply-To: <fcaeb9bf0908222107i6d999335r998a304aaa3cd405@mail.gmail.com>
On Sun, Aug 23, 2009 at 11:07:39AM +0700, Nguyen Thai Ngoc Duy wrote:
> It is (and should be worked around with GIT_CEILING_DIRECTORIES).
> Unfortunately in my test, it could not chdir() back when it failed to
> find gitdir. chdir() was called with an absolute directory, and one
> directory in that path was inaccesible, leading another die("Cannot
> come back to cwd"). This one is fatal and should not be ignored. I
> don't know whether having an inaccesible parent directory is a real
> scenario, as lots of tools would break.
Hmm, good point. Some of those die()s really can't be removed, because
we have munged state in a way that can't be recovered (or is hard to
recover).
Also, thinking about it a bit more, I'm not sure it is correct to turn
such a die() into a "return -1" without passing more information along
to the caller. Because there are really three possible outcomes:
1. we are in a git repo
2. we are not in a git repo
3. some error occurred and we could not determine which
of (1) and (2) is the case
And the "gently" bit really just refers to (1) versus (2). It is
tempting to fold (3) into (2), but I'm not sure that is the right thing
to do; some callers (including script callers not under our control) may
care about the distinction (though I think we already blur it; for
example, a non-existent '.git' regular file is treated the same as one
which we couldn't stat for permission problems).
So perhaps the right thing is to either pass back a tri-state status, or
to have an extra_gently mode, either of which could be used by "git
help". The problem with either is that the current setup process is not
amenable to exiting in the middle -- it really may leave us in a weird
and buggy state due to the chdir.
So short of major surgery on the setup procedure, I think we may have to
leave this bug be for now (especially because I'm not convinced the
setup of a non-executable parent directory isn't a little bit crazy).
-Peff
next prev parent reply other threads:[~2009-08-25 4:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-21 20:05 hitting home directory's parent Daniel Convissor
2009-08-22 4:10 ` Nguyen Thai Ngoc Duy
2009-08-22 15:05 ` Daniel Convissor
2009-08-22 16:20 ` Nguyen Thai Ngoc Duy
2009-08-22 16:22 ` Nguyen Thai Ngoc Duy
2009-08-22 18:16 ` Jeff King
2009-08-23 4:07 ` Nguyen Thai Ngoc Duy
2009-08-25 4:42 ` Jeff King [this message]
2009-08-23 5:12 ` Daniel Convissor
2009-08-25 4:48 ` Jeff King
2009-08-23 4:42 ` Daniel Convissor
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=20090825044236.GA13738@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=danielc@analysisandsolutions.com \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
/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).