Git Bug Report

Git Bug Report

[Randall Alfaro]

[-- Attachment #1: Type: text/plain, Size: 306 bytes --]

Hello Git Community.

While using the Git tool on windows and a custom path for a private
SSH (due to some policies and guidelines I've got to follow), I
encountered a particular issue.

I think this is related to a bug, I attach the template generated by
git bugreport down below.
Regards!
Randall Alfaro

[-- Attachment #2: git-bugreport-2022-04-14-0107.txt --]
[-- Type: text/plain, Size: 1662 bytes --]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
R/ Set up GIT_SSH_COMMAND or core.sshCommand

What did you expect to happen? (Expected behavior)
R/ To be able to fetch/pull/push

What happened instead? (Actual behavior)
R/ "Disallowed command" was obtained by the server

What's different between what you expected and what actually happened?
R/ Any GIT command worked.

Anything else you want to add:
While debugging and troubleshooting, I noticed that the command "git-upload-pack" was getting sent two times. This is the
command sent to the server after connecting to ssh (with -vvv)
git-upload-pack '<PRIVATE PATH>' -o SendEnv=GIT_PROTOCOL -p <PRIVATE_PORT> git@<PRIVATE URL> git-upload-pack '<PRIVATE PATH>'

After debugging as well the normal behavior when ssh is used but without GIT_SSH_COMMAND or core.sshCommand (by using the .ssh folder and config),
the command is indeed only sent one time.

My hypothesis is that this might be a bug, and sending the command two times might be causing GitLab to respond with the "Disallowed command"
error.

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.35.2.windows.1
cpu: x86_64
built from commit: 518ccba2352ce721cabbbf2933869c3c3313d1c3
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Windows 10.0 19042 
compiler info: gnuc: 11.2
libc info: no libc information available
$SHELL (typically, interactive shell): <unset>


[Enabled Hooks]

Re: git bug report

[Junio C Hamano]

Paul Watson <pwatson2@wellmed.net> writes:

> 9:43:55.45 2023-08-04  C:\src\t\scripts>TYPE .\t1.txt
> this is t1.txt

> 9:43:57.92 2023-08-04  C:\src\t\scripts>TYPE .\t2.txt
> this is t2.txt
>
> 9:43:58.04 2023-08-04  C:\src\t\scripts>"C:\Program Files\Git\cmd\git.exe" diff --exit-code --no-index  --ignore-all-space  --shortstat  .\t1.txt .\t2.txt
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> 9:43:58.14 2023-08-04  C:\src\t\scripts>ECHO %ERRORLEVEL%
> 0

This is not specific to Windows port and it can be reproduced on a
random Linux box.

    $ echo one >1
    $ echo two >2
    $ git diff --no-index --shortstat 1 2; echo "<<$?>>"
     1 file changed, 1 insertion(+), 1 deletion(-)
    <<1>>
    $ git diff --no-index --shortstat -w 1 2; echo "<<$?>>"
     1 file changed, 1 insertion(+), 1 deletion(-)
    <<0>>

Note that I omitted "--exit-code" in the above reproduction, as it
is always used in the no-index mode.  There seems to be interaction
with "-w" and not using "-p", as this is not limited to "--shortstat".

    $ git diff --no-index -w --stat 1 2; echo "<<$?>>"
     1 => 2 | 2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
    <<0>>

    $ git diff --no-index -w --numstat 1 2; echo "<<$?>>"
    1	1	1 => 2
    <<0>>

All of the above that exits with 0 status will exit with 1 when -p
is added to the command line.

Also, this is not limited to the no-index mode.

    $ echo one >1
    $ git add 1
    $ echo two >1
    $ git diff --exit-code --numstat 1; echo "<<$?>>"
    1	1	1
    <<1>>
    $ git diff --exit-code --numstat -w 1; echo "<<$?>>"
    1	1	1
    <<0>>

So the minimum reproduction seems to be

  * the diff machinery is asked to do --exit-code (no-index
    implicitly does it)
  * -w is used
  * -p is *not* used
  * to compare two different files.

Thanks for a bug report.

Patches welcome ;-)

RE: git bug report

[rsbecker]

On Friday, August 4, 2023 12:46 PM, Paul Watson wrote:
>Thank you for filling out a Git bug report!
>Please answer the following questions to help us understand your issue.
>
>What did you do before the bug happened? (Steps to reproduce your issue)
>
>9:43:55.45 2023-08-04  C:\src\t\scripts>TYPE .\t1.txt this is t1.txt
>
>9:43:57.92 2023-08-04  C:\src\t\scripts>TYPE .\t2.txt this is t2.txt
>
>9:43:58.04 2023-08-04  C:\src\t\scripts>"C:\Program Files\Git\cmd\git.exe" diff --exit-
>code --no-index  --ignore-all-space  --shortstat  .\t1.txt .\t2.txt
>1 file changed, 1 insertion(+), 1 deletion(-)

Can you retry this without --shortstat so we can see what git is reporting as a difference.

Thanks,
Randall

git bug report

[Paul Watson]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)

9:43:55.45 2023-08-04  C:\src\t\scripts>TYPE .\t1.txt
this is t1.txt

9:43:57.92 2023-08-04  C:\src\t\scripts>TYPE .\t2.txt
this is t2.txt

9:43:58.04 2023-08-04  C:\src\t\scripts>"C:\Program Files\Git\cmd\git.exe" diff --exit-code --no-index  --ignore-all-space  --shortstat  .\t1.txt .\t2.txt
1 file changed, 1 insertion(+), 1 deletion(-)

9:43:58.14 2023-08-04  C:\src\t\scripts>ECHO %ERRORLEVEL%
0

What did you expect to happen? (Expected behavior)

I expected that the exit code from `git diff` would be 1, or something non-zero because the files are different.

What happened instead? (Actual behavior)

The exit code was zero (0).

What's different between what you expected and what actually happened?

Zero (0) is not one (1). :-)

Anything else you want to add:

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.39.2.windows.1
cpu: x86_64
built from commit: a82fa99b36ddfd643e61ed45e52abe314687df67
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Windows 10.0 19044 
compiler info: gnuc: 12.2
libc info: no libc information available
$SHELL (typically, interactive shell): <unset>
    PowerShell 7.3.6 Console on Windows 10

[Enabled Hooks]
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or intended recipient’s authorized agent, the reader is hereby
notified that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.

Git bug report

[Camden Narzt]

What did you do before the bug happened? (Steps to reproduce your issue)

Enabled core.fsmonitor in ~/.gitconfig

What did you expect to happen? (Expected behavior)

Faster git status, or at the very least not slower.

What happened instead? (Actual behavior)

Significantly slower git status.

What's different between what you expected and what actually happened?

With the fsmonitor git status takes like 2-8s when normally it's under 1s, I expected it to be faster than normal.

Anything else you want to add:

I've tried apple's git (used to generate this report) and the one from homebrew (2.38.0). The repo doesn’t seem to matter much, some are a bit faster than others, but they’re all really slow.

I tried to track down the slowness using trace2.perfTarget and from that it seemed to spend a lot of time doing fsync.




[System Info]
git version:
git version 2.37.0 (Apple Git-136)
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 21.6.0 Darwin Kernel Version 21.6.0: Mon Aug 22 20:17:10 PDT 2022; root:xnu-8020.140.49~2/RELEASE_X86_64 x86_64
compiler info: clang: 14.0.0 (clang-1400.0.29.201)
libc info: no libc information available
$SHELL (typically, interactive shell): /usr/local/bin/bash


[Enabled Hooks]

Re: Git Bug report

[Aaron Schrab]

At 09:22 -0700 06 Oct 2011, Junio C Hamano <gitster@pobox.com> wrote:
>Yeah, after thinking about it a bit more, whenever we see ".git" during
>the upward discovery process, we should always warn if we know it is _not_
>a GIT_DIR before looking for another ".git" at higher levels, as anything
>in that directory cannot be added. If we cannot tell if it is or is not
>a GIT_DIR, we should error out---the reason we cannot tell most likely is
>because we cannot read it, and such a file, if it is not a GIT_DIR, cannot
>be tracked in the real GIT_DIR at a higher level, and if it is a GIT_DIR,
>we cannot use it to record updates or inspect existing history.

Yes, I think that sounds like a good idea.  That should also solve a 
related problem that I noticed while checking out the current behaviour.

Currently if the .git directory of a submodule is inaccessible running 
`git status` from anywhere in the parent repository (including within 
the submodule) will cause git to recursively call itself until enough 
resources are used to prevent further forking.  I then tried this with 
the patch from earlier in the thread applied, but with the call to 
error() changed to call die() instead.  With that change it quickly 
failed with a useful error message.

Re: Git Bug report

[Phil Hord]

On Thu, Oct 6, 2011 at 12:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Phil Hord <phil.hord@gmail.com> writes:
>
>> On Oct 5, 2011 9:14 PM, "SZEDER Gábor" <szeder@ira.uka.de> wrote:
>>>
>>> On Wed, Oct 05, 2011 at 05:44:54PM -0700, Junio C Hamano wrote:
>>> > SZEDER Gábor <szeder@ira.uka.de> writes:
>>> >
>>> > > And what about unreadable .git files?
>>> >
>>> > Having then inside a working tree is so sick that I do not think it
>>> > deserves consideration.
>>>
>>> I'm not sure why is this any different than having a .git directory
>>> that is not a repository inside a working tree.
>>
>> What should happen here? Ignore it and keep searching? Or fail?
>>
>> I just added some common gitfile detection code and I noticed that the
>> oddball case now is the one that dies on error rather than continuing to
>> search for alternate explanations.  I left the oddball behavior assuming it
>> is desireable, but now you have me rethinking it.
>
> Yeah, after thinking about it a bit more, whenever we see ".git" during
> the upward discovery process, we should always warn if we know it is _not_
> a GIT_DIR before looking for another ".git" at higher levels, as anything
> in that directory cannot be added. If we cannot tell if it is or is not
> a GIT_DIR, we should error out---the reason we cannot tell most likely is
> because we cannot read it, and such a file, if it is not a GIT_DIR, cannot
> be tracked in the real GIT_DIR at a higher level, and if it is a GIT_DIR,
> we cannot use it to record updates or inspect existing history.
>
> How's that sound as a guideline?

Ok.  Three cases, then:

if .git is valid, we use it.
If .git is bogus, we warn about it and keep searching.
If .git is unverifiable (permissions, IO-fail, etc.), we die.

Phil

Re: Git Bug report

[Phil Hord]

On 10/5/11, SZEDER Gábor <szeder@ira.uka.de> wrote:
> On Wed, Oct 05, 2011 at 05:44:54PM -0700, Junio C Hamano wrote:
>> SZEDER Gábor <szeder@ira.uka.de> writes:
>>
>> > And what about unreadable .git files?
>>
>> Having then inside a working tree is so sick that I do not think it
>> deserves consideration.
>
> I'm not sure why is this any different than having a .git directory
> that is not a repository inside a working tree.

What should happen here? Ignore it and keep searching? Or fail?

I just added some common gitfile detection code and I noticed that the
oddball case now is the one that dies on error rather than continuing
to search for alternate explanations. I left the oddball behavior
assuming it is desireable, but now you have me rethinking it.

Phil

Re: Git Bug report

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

>  If we cannot tell if it is or is not
> a GIT_DIR, we should error out---the reason we cannot tell most likely is
> because we cannot read it, and such a file, if it is not a GIT_DIR, cannot
> be tracked in the real GIT_DIR at a higher level, and if it is a GIT_DIR,
> we cannot use it to record updates or inspect existing history.

Plus, the user may have removed the permission on the .git directory by
mistake, and it would be very surprising behavior if git ran without
complaining using a higher level GIT_DIR (i.e. a more or less arbitrary
repo as far as the user is concerned ...)

> How's that sound as a guideline?

Sounds reasonable, yes.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Git Bug report

[Junio C Hamano]

Phil Hord <phil.hord@gmail.com> writes:

> On Oct 5, 2011 9:14 PM, "SZEDER Gábor" <szeder@ira.uka.de> wrote:
>>
>> On Wed, Oct 05, 2011 at 05:44:54PM -0700, Junio C Hamano wrote:
>> > SZEDER Gábor <szeder@ira.uka.de> writes:
>> >
>> > > And what about unreadable .git files?
>> >
>> > Having then inside a working tree is so sick that I do not think it
>> > deserves consideration.
>>
>> I'm not sure why is this any different than having a .git directory
>> that is not a repository inside a working tree.
>
> What should happen here? Ignore it and keep searching? Or fail?
>
> I just added some common gitfile detection code and I noticed that the
> oddball case now is the one that dies on error rather than continuing to
> search for alternate explanations.  I left the oddball behavior assuming it
> is desireable, but now you have me rethinking it.

Yeah, after thinking about it a bit more, whenever we see ".git" during
the upward discovery process, we should always warn if we know it is _not_
a GIT_DIR before looking for another ".git" at higher levels, as anything
in that directory cannot be added. If we cannot tell if it is or is not
a GIT_DIR, we should error out---the reason we cannot tell most likely is
because we cannot read it, and such a file, if it is not a GIT_DIR, cannot
be tracked in the real GIT_DIR at a higher level, and if it is a GIT_DIR,
we cannot use it to record updates or inspect existing history.

How's that sound as a guideline?

Re: Git Bug report

[SZEDER Gábor]

On Wed, Oct 05, 2011 at 05:44:54PM -0700, Junio C Hamano wrote:
> SZEDER Gábor <szeder@ira.uka.de> writes:
> 
> > And what about unreadable .git files?
> 
> Having then inside a working tree is so sick that I do not think it
> deserves consideration.

I'm not sure why is this any different than having a .git directory
that is not a repository inside a working tree.

> Please don't troll immediately after a big release.

I didn't mean to troll; it just happened that I came across this issue
this weekend while trying to optimize the bash completion code...

Re: Git Bug report

[Junio C Hamano]

SZEDER Gábor <szeder@ira.uka.de> writes:

> And what about unreadable .git files?

Having then inside a working tree is so sick that I do not think it
deserves consideration.

Please don't troll immediately after a big release.

Re: Git Bug report

[SZEDER Gábor]

On Wed, Oct 05, 2011 at 09:49:00AM -0700, Junio C Hamano wrote:
> Fredrik Gustafsson <iveqy@iveqy.com> writes:
> 
> > On Tue, Oct 04, 2011 at 05:24:03PM -0400, Federico Lucifredi wrote:
> >>  Found a minor bug in git today - the error message reported is not
> >> correct when trying to access a repo that is not accessible
> >> permission-wise:
> >> 
> >> > federico@skyplex:/etc$ git log
> >> > fatal: Not a git repository (or any of the parent directories): .git
> >> 
> >> with correct access permissions, everything works as expected.
> >
> > So if:
> > .git/ is a directory with not enought permissions.
> > ../.git/ is a directory with enought permissions.
> >
> > git would today use ../.git. You suggest that git instead would die
> > because a .git/ exists? (I'm not saying this is wrong or right).
> 
> For that matter, if you have .git/ that is a directory but is not a
> repository, and ../.git/ that is, the same situation would arise. I do not
> think we should die because .git/ is not a git repository. I do not know
> if we should even warn about it.

And what about unreadable .git files?

~/tmp/git/outside$ git init
Initialized empty Git repository in /home/szeder/tmp/git/outside/.git/
~/tmp/git/outside$ mkdir inside repo
~/tmp/git/outside$ cd inside/
~/tmp/git/outside/inside$ git init --separate-git-dir=../repo
Initialized empty Git repository in /home/szeder/tmp/git/outside/repo/
~/tmp/git/outside/inside$ git rev-parse --git-dir
/home/szeder/tmp/git/outside/repo
~/tmp/git/outside/inside$ chmod a-r .git
~/tmp/git/outside/inside$ git rev-parse --git-dir
fatal: Error opening '.git': Permission denied

Or a non-gitfile .git file?

~/tmp/git/outside/inside$ chmod a+r .git
~/tmp/git/outside/inside$ echo foo >.git
~/tmp/git/outside/inside$ git rev-parse --git-dir
fatal: Invalid gitfile format: .git

Shouldn't these also be ignored?


Best,
Gábor

Re: Git Bug report

[Nguyen Thai Ngoc Duy]

On Thu, Oct 6, 2011 at 3:49 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> So if:
>> .git/ is a directory with not enough permissions.
>> ../.git/ is a directory with enough permissions.
>>
>> git would today use ../.git. You suggest that git instead would die
>> because a .git/ exists? (I'm not saying this is wrong or right).
>
> For that matter, if you have .git/ that is a directory but is not a
> repository, and ../.git/ that is, the same situation would arise. I do not
> think we should die because .git/ is not a git repository. I do not know
> if we should even warn about it.

Probably not. On the other hand we should show user how we ignored
.git if we find no good repository in the end. So maybe it's a good
idea to queue up warnings and only print before git calls die("Not a
repository").
-- 
Duy

Re: Git Bug report

[Federico Lucifredi]

On Wed, 2011-10-05 at 08:11 +0200, Johannes Sixt wrote:
> >> federico@skyplex:/etc$ git log
> >> fatal: Not a git repository (or any of the parent directories): .git
> > 
> > with correct access permissions, everything works as expected.
> 
> And the correct error message is...?

".git: permission denied" -- no need to be fatal (there could
be ../.git, etc - fatal comes only if those don't exist). 

It could fail silently if one of the parents exists, but in the fatal
scenario, I should be told that it was by permission denied. Currently,
I am told there is no git repo where I know there to be one, which means
"what happened to my repo" is the next question in the user's head.
"it's there but it is broke" is the subtext one gets from this error. it
should be "it is there, I cannot get to it".

> >> drwx------   8 root root      4096 2011-10-03 16:53 .git
> 
> Assuming that you expected something like this:
> 
> fatal: .git: permission denied
> 
> it is hard to argue that a directory that happens to be named .git, but
> was sealed by its owner should be assumed to be a git repository, albeit
> one that we do not have access to. "Not a git repository" is an equally
> justifyable error message, IMHO.

An error message should help resolve the error in question, not grade
the user's smarts. Here I as a user had an expectation that there was a
git repository for /etc ("I set up one!") and figured the permission
issue with my own wits (well, I did not need to because it was /etc, but
in the general perm-denied case I would have had to), by looking at the
dir because the message gave me no useful information on the cause of
the problem.

Thanks -Federico
-- 

_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
(Federico L. Lucifredi) - federico at canonical.com - GnuPG 0x4A73884C

Re: Git Bug report

[Junio C Hamano]

Fredrik Gustafsson <iveqy@iveqy.com> writes:

> On Tue, Oct 04, 2011 at 05:24:03PM -0400, Federico Lucifredi wrote:
>>  Found a minor bug in git today - the error message reported is not
>> correct when trying to access a repo that is not accessible
>> permission-wise:
>> 
>> > federico@skyplex:/etc$ git log
>> > fatal: Not a git repository (or any of the parent directories): .git
>> 
>> with correct access permissions, everything works as expected.
>
> So if:
> .git/ is a directory with not enought permissions.
> ../.git/ is a directory with enought permissions.
>
> git would today use ../.git. You suggest that git instead would die
> because a .git/ exists? (I'm not saying this is wrong or right).

For that matter, if you have .git/ that is a directory but is not a
repository, and ../.git/ that is, the same situation would arise. I do not
think we should die because .git/ is not a git repository. I do not know
if we should even warn about it.

Re: Git Bug report

[Fredrik Gustafsson]

On Tue, Oct 04, 2011 at 05:24:03PM -0400, Federico Lucifredi wrote:
>  Found a minor bug in git today - the error message reported is not
> correct when trying to access a repo that is not accessible
> permission-wise:
> 
> > federico@skyplex:/etc$ git log
> > fatal: Not a git repository (or any of the parent directories): .git
> 
> with correct access permissions, everything works as expected.

So if:
.git/ is a directory with not enought permissions.
../.git/ is a directory with enought permissions.

git would today use ../.git. You suggest that git instead would die
because a .git/ exists? (I'm not saying this is wrong or right).

-- 
Med vänliga hälsningar
Fredrik Gustafsson

E-post: iveqy@iveqy.com
Tel. nr.: 0733 60 82 74

Re: Git Bug report

[Johannes Sixt]

Am 10/4/2011 23:24, schrieb Federico Lucifredi:
> Hello Git list,
>  Found a minor bug in git today - the error message reported is not
> correct when trying to access a repo that is not accessible
> permission-wise:
> 
>> federico@skyplex:/etc$ git log
>> fatal: Not a git repository (or any of the parent directories): .git
> 
> with correct access permissions, everything works as expected.

And the correct error message is...?

>> drwx------   8 root root      4096 2011-10-03 16:53 .git

Assuming that you expected something like this:

fatal: .git: permission denied

it is hard to argue that a directory that happens to be named .git, but
was sealed by its owner should be assumed to be a git repository, albeit
one that we do not have access to. "Not a git repository" is an equally
justifyable error message, IMHO.

-- Hannes

Git Bug report

[Federico Lucifredi]

Hello Git list,
 Found a minor bug in git today - the error message reported is not
correct when trying to access a repo that is not accessible
permission-wise:

> federico@skyplex:/etc$ git log
> fatal: Not a git repository (or any of the parent directories): .git

with correct access permissions, everything works as expected.

> federico@skyplex:/etc$ sudo git log
> commit 10a1d0eefcc100a513a9dff46839cff2c4f9b5a0
> Author: root <root@skyplex>
> Date:   Mon Oct 3 16:53:33 2011 -0400
>
>    saving uncommitted changes in /etc prior to apt run
>
> commit 2abb2b397631c7f48757bbcb029ebc38e37659d6
> Author: federico <federico@skyplex>
> Date:   Mon Oct 3 16:50:16 2011 -0400
>
>    updating firefox packages next
>federico@skyplex:/etc$ 

> drwx------   8 root root      4096 2011-10-03 16:53 .git

That's it... I am not subscribed to the list, CC me in reply as needed.

Best -Federico

-- 

_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
(Federico L. Lucifredi) - federico at canonical.com - GnuPG 0x4A73884C