From: John Keeping <john@keeping.me.uk>
To: Ville Walveranta <walveranta@gmail.com>
Cc: Git List <git@vger.kernel.org>, Philip Oakley <philipoakley@iee.org>
Subject: Re: Git 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!
Date: Sat, 2 Nov 2013 20:20:41 +0000 [thread overview]
Message-ID: <20131102202041.GF24023@serenity.lan> (raw)
In-Reply-To: <CACbqpSspsUvw3QXnSmOXA2boenh3y4DjHO-813OTna7cpSXkZQ@mail.gmail.com>
On Sat, Nov 02, 2013 at 02:42:04PM -0500, Ville Walveranta wrote:
> Without the functionality such as that 1.7.9.5 still offered, it is
> now not possible to use "git-rev-parse --is-inside-work-tree" to
> detect whether the current location is controlled by a git repository
> without emitting the "fatal: Not a git
> repository (or any of the parent directories): .git" error message,
> when it is not. There is no functional "--quiet" switch, and the usual
> error/std redirection to /dev/null doesn't seem to work to squelch the
> output.
How doesn't redirection work? The message is printed to stderr; the
snippet I posted below does indeed squelch the output.
> If "--is-inside-git-dir" and "--is-inside-work-tree" are indeed not
> supposed to emit "false" when outside of a git repository, perhaps
> there is another way I can use (in a bash script) to cleanly detect
> whether a specific path is part of a git repo or not?
Something like this, maybe?
(cd "$dir" && git rev-parse --git-dir >/dev/null 2>&1)
> On Sat, Nov 2, 2013 at 12:03 PM, Philip Oakley <philipoakley@iee.org> wrote:
> > From: "John Keeping" <john@keeping.me.uk>
> > Sent: Saturday, November 02, 2013 2:06 PM
> >
> >> On Sat, Nov 02, 2013 at 01:47:02PM -0000, Philip Oakley wrote:
> >>>
> >>> From: "John Keeping" <john@keeping.me.uk>
> >>> Sent: Saturday, November 02, 2013 10:58 AM
> >>> > On Fri, Nov 01, 2013 at 06:19:51PM -0500, Ville Walveranta wrote:
> >>> >> "git-rev-parse --is-inside-git-dir" outputs "fatal: Not a git
> >>> >> repository (or any of the parent directories): .git", instead of
> >>> >> "false" when outside of a git directory. "--is-inside-work-tree"
> >>> >> behaves the same way. Both commands work correctly (i.e. output
> >>> >> "true") when inside a git directory, or inside a work tree,
> >>> >> respectively.
> >>> >
> >>> > I think that's intentional - and it looks like the behaviour has
> >>> > not
> >>> > changed since these options were added. With the current behaviour
> >>> > you
> >>> > get three possible outcomes from "git
> >>> > rev-parse --is-inside-work-tree":
> >>> >
> >>> > if worktree=$(git rev-parse --is-inside-work-tree 2>/dev/null)
> >>> > then
> >>> > if test "$worktree" = true
> >>> > then
> >>> > echo 'inside work tree'
> >>> > else
> >>> > echo 'in repository, but not in work tree'
> >>> > fi
> >>> > else
> >>> > echo 'not in repository'
> >>> > fi
> >>> > --
next prev parent reply other threads:[~2013-11-02 20:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-01 23:19 Git 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output! Ville Walveranta
2013-11-02 10:24 ` Øystein Walle
2013-11-02 10:58 ` John Keeping
2013-11-02 13:47 ` Philip Oakley
2013-11-02 14:06 ` John Keeping
2013-11-02 17:03 ` Philip Oakley
2013-11-02 19:42 ` Ville Walveranta
2013-11-02 20:20 ` John Keeping [this message]
2013-11-02 22:58 ` Ville Walveranta
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=20131102202041.GF24023@serenity.lan \
--to=john@keeping.me.uk \
--cc=git@vger.kernel.org \
--cc=philipoakley@iee.org \
--cc=walveranta@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.