Re: Git 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!

2013-11-02 Thread Ville Walveranta
Yes, stderr redirection in a subshell seems to work ok.  Since I'm
creating a small git utility script I ended up doing:

--
#!/bin/bash

(git rev-parse --git-dir >/dev/null 2>&1)

if [ $? -ne 0 ] ; then
  echo "Not in a git repo"
else
  echo "Git repo; proceeding.."
  # more logic..
fi
-- 

That works! Thanks for your help!

Ville

On Sat, Nov 2, 2013 at 3:20 PM, John Keeping  wrote:
> 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  wrote:
>> > From: "John Keeping" 
>> > Sent: Saturday, November 02, 2013 2:06 PM
>> >
>> >> On Sat, Nov 02, 2013 at 01:47:02PM -, Philip Oakley wrote:
>> >>>
>> >>> From: "John Keeping" 
>> >>> 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
>> >>> > --
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Git 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!

2013-11-02 Thread John Keeping
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  wrote:
> > From: "John Keeping" 
> > Sent: Saturday, November 02, 2013 2:06 PM
> >
> >> On Sat, Nov 02, 2013 at 01:47:02PM -, Philip Oakley wrote:
> >>>
> >>> From: "John Keeping" 
> >>> 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
> >>> > --
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Git 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!

2013-11-02 Thread Ville Walveranta
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.

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?

Thanks for any insights on this! :-)

Ville

On Sat, Nov 2, 2013 at 12:03 PM, Philip Oakley  wrote:
> From: "John Keeping" 
> Sent: Saturday, November 02, 2013 2:06 PM
>
>> On Sat, Nov 02, 2013 at 01:47:02PM -, Philip Oakley wrote:
>>>
>>> From: "John Keeping" 
>>> 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
>>> > --
>>>
>>>
>>> Shouldn't this case which produces "fatal:..." need to be documented
>>> in
>>> the man page?
>>> https://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html
>>> doesn't mention it.
>>
>>
>> I'm not sure where it should go in there.  The documentation for
>> --git-dir says:
>>
>>   If $GIT_DIR is not defined and the current directory is not detected
>>   to lie in a Git repository or work tree print a message to stderr
>> and
>>   exit with nonzero status.
>>
>> but there reality is that if you do not specify --parseopt
>> or --sq-quote
>> then the command expects to be run in a Git repository [1], so perhaps
>> it would be better to say something under "Operation Modes" or in the
>> description.
>>
>>
>> [1] After taking account of $GIT_DIR, $GIT_WORK_TREE, and arguments to
>>the base "git" driver that affect these variables.
>>
>
> Yes, but given Ville's surprise and the need for special prior knowledge
> of the points you raised, I still think that some short note is needed.
>
> It can/could be read that you need to invoke --git-dir as an option
> before the mentioned die() exit is taken, rather than it applying to
> all(?) the path relevant options.
>
> Either the --git-dir condition needs to say it also applies
> to --is-inside-git-dir and --is-inside-work-tree
> (and --is-bare-repository?), or add a "see --git-dir preconditions." to
> each of those options. It's easy to be wise after the event hence my
> preference for a suitable note.
>
> regards
>
> Philip
>
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Git 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!

2013-11-02 Thread Philip Oakley

From: "John Keeping" 
Sent: Saturday, November 02, 2013 2:06 PM

On Sat, Nov 02, 2013 at 01:47:02PM -, Philip Oakley wrote:

From: "John Keeping" 
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
> --


Shouldn't this case which produces "fatal:..." need to be documented
in
the man page?
https://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html
doesn't mention it.


I'm not sure where it should go in there.  The documentation for
--git-dir says:

  If $GIT_DIR is not defined and the current directory is not detected
  to lie in a Git repository or work tree print a message to stderr
and
  exit with nonzero status.

but there reality is that if you do not specify --parseopt
or --sq-quote
then the command expects to be run in a Git repository [1], so perhaps
it would be better to say something under "Operation Modes" or in the
description.


[1] After taking account of $GIT_DIR, $GIT_WORK_TREE, and arguments to
   the base "git" driver that affect these variables.



Yes, but given Ville's surprise and the need for special prior knowledge
of the points you raised, I still think that some short note is needed.

It can/could be read that you need to invoke --git-dir as an option
before the mentioned die() exit is taken, rather than it applying to
all(?) the path relevant options.

Either the --git-dir condition needs to say it also applies
to --is-inside-git-dir and --is-inside-work-tree
(and --is-bare-repository?), or add a "see --git-dir preconditions." to
each of those options. It's easy to be wise after the event hence my 
preference for a suitable note.


regards

Philip


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Git 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!

2013-11-02 Thread John Keeping
On Sat, Nov 02, 2013 at 01:47:02PM -, Philip Oakley wrote:
> From: "John Keeping" 
> 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
> > --
> 
> 
> Shouldn't this case which produces "fatal:..." need to be documented in 
> the man page?
> https://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html 
> doesn't mention it.

I'm not sure where it should go in there.  The documentation for
--git-dir says:

   If $GIT_DIR is not defined and the current directory is not detected
   to lie in a Git repository or work tree print a message to stderr and
   exit with nonzero status.

but there reality is that if you do not specify --parseopt or --sq-quote
then the command expects to be run in a Git repository [1], so perhaps
it would be better to say something under "Operation Modes" or in the
description.


[1] After taking account of $GIT_DIR, $GIT_WORK_TREE, and arguments to
the base "git" driver that affect these variables.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Git 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!

2013-11-02 Thread Philip Oakley

From: "John Keeping" 
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
--



Shouldn't this case which produces "fatal:..." need to be documented in 
the man page?
https://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html 
doesn't mention it.


Philip 


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Git 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!

2013-11-02 Thread John Keeping
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Git 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!

2013-11-02 Thread Øystein Walle
Ville Walveranta  gmail.com> writes:

> 
> "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.
> 
> To test, I installed git 1.8.4.2 initially from
> https://launchpad.net/~git-core/+archive/ppa for Ubuntu 12.04.3, and
> then also compiled it from source, but both seem to behave the same
> way. The problem is not yet present in version 1.7.9.5.
> 
> Thanks,
> 
> Ville Walveranta
>

Hi,

I thought I'd try to bisect this but I ended up discovering that I get
the exact same behaviour with both 1.7.9.5 and 1.8.4.2. 1.7.9.5 will
also output 'fatal: ...' like 1.8.4.2 does.

Both version will however behave as expected if you provide --git-dir
and --work-tree:

$ pwd
/home/osse
$ git --version
git version 1.8.4.2
$ git --git-dir=/home/osse/git/.git \
  --work-tree=/home/osse/git\
rev-parse  --is-inside-work-tree
false

Ditto for --is-inside-git-dir.

Incidentally I discovered that the new -C option does *not* behave this
way:

$ git --version
git version 1.8.5.rc0.23.gaa27064
$ git -C /home/osse/git rev-parse --is-inside-work-tree
true

But given that the purpose of the -C option is to make Git behave as if
you were in that directory this is perhaps expected behaviour.

Regards,
Øsse



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html