VSCode GitLive extension causing infinite looping calls to `git blame` on .gitignored file

[wsrast]

Open any file which is marked as ignored in your .gitignore file and you'll get the following error repeatedly in your "Output">"Git" window:

fatal: no such path <path> in <commit SHA>

It's coming from a git blame command comparing two commits.

git blame -s -l --encoding=UTF-8 --reverse <commit>..<commit> <path>

The only fix is to disable the GitLive extension.

[Steakeye]

Hi @wsrast,

At first glance I'm not able to reproduce your issue.

In order to investigate this further, could you provide us with more information about your setup? It would be really helpful if you could tell us the following:

• Operating System, name and version number
• VSCode version
• GitLive version

[wsrast]

OS: MacOS 12.3.1 VSCode: 1.66.2 GitLive version: 15.0.6

[Steakeye]

Thanks @wsrast,

We're taking a look at repeating your issue and will get back to you when we have a conclusion.

[Steakeye]

Hi @wsrast,

We've been looking into this today and it would be helpful if we could get a bit more information from you.

If the project you're working on happens to have a public repo, then it would be great for us to know what the project is as well as the branch you were on, so that we might more accurately try to replicate what you've experienced.

Next, would it be possible for you to try running VSCode with GitLive enabled and confirm that it really is an infinite loop, that is to say, running the VSCode with a git ignored file open in the editor, and then see if the output tab with the Git logs ever stops, after more than just a few minutes perhaps?

In addition to this, could you email us at support@git.live with a text file containing as much of the output logs for Git as possible; obviously within reason, anything more than 1 MB is probably too much, our largest log output has been under 100 kB.

If we can't get access to the repo as it's private, that's fine but it would also be useful to know how many branches exist on the project that are ahead of master and/or the branch that you were on at the time.

I appreciate this might take a little bit of your time but we'd love to be able to solve this for you with a bit more help from you 😄

Thanks, Andrew

[wsrast]

Will give that a shot and get back to you. It's a private repo, but the rest I can do.

[Steakeye]

Much appreciate! 👍🏽

[Steakeye]

Hi @wsrast,

Just wondered if you'd had a chance to confirm the log output for all the git blame calls is actually infinite, or at least continuing beyond 5 minutes for example?

If it is the case that the log output is going on for what seems likfe forever, it's be great for us to analyse the log output; also that estimate of the branch count for your project as mentioned before would be really helpful 😄

Cheers, Andrew

[wsrast]

I've let it run for the past 10 minutes and it's still going. We have ~90 branches currently in the origin remote, and I have less than a dozen locally.

[2022-05-10T19:57:01.851Z] > git blame -s -l --encoding=UTF-8 acbd3e652a3e3d88096c5e45febd382756bc31f9..ec0d61ef4b3a6eb1413444d42c210a99bcaa615f packages/api/.env [11ms]
[2022-05-10T19:57:01.851Z] fatal: no such path packages/api/.env in ec0d61ef4b3a6eb1413444d42c210a99bcaa615f
[2022-05-10T19:57:02.665Z] > git fetch [813ms]
[2022-05-10T19:57:02.722Z] > git status -z -uall [56ms]
[2022-05-10T19:57:02.732Z] > git symbolic-ref --short HEAD [9ms]
[2022-05-10T19:57:02.745Z] > git for-each-ref --format=%(refname)%00%(upstream:short)%00%(objectname)%00%(upstream:track)%00%(upstream:remotename)%00%(upstream:remoteref) refs/heads/development refs/remotes/development [12ms]
[2022-05-10T19:57:02.755Z] > git remote --verbose [8ms]
[2022-05-10T19:57:02.785Z] > git for-each-ref --sort -committerdate --format %(refname) %(objectname) %(*objectname) [39ms]
[2022-05-10T19:57:02.803Z] > git config --get commit.template [9ms]
[2022-05-10T19:57:02.818Z] > git blame -s -l --encoding=UTF-8 acbd3e652a3e3d88096c5e45febd382756bc31f9..ec0d61ef4b3a6eb1413444d42c210a99bcaa615f packages/api/.env [14ms]
[2022-05-10T19:57:02.818Z] fatal: no such path packages/api/.env in ec0d61ef4b3a6eb1413444d42c210a99bcaa615f

The above repeats in the logs infinitely as far as I can tell whenever a .gitignored file is the active file.

[Steakeye]

Hi @wsrast ,

Thank you very much for your update; it's good to know about the size of your branch in terms of branches; I'm taking it that these are all open branches?

I also wish to clarify something regarding the output logs.

GitLive builds up deltas between your local files and remote versions of the same file; we do this so we can show you those differences and you can easily cherry pick differences; it's this feature that triggers the git blame comparisons.

Are you sure the output logs are exactly repeating? That is to say for example:

[2022-05-10T19:57:02.818Z] > git blame -s -l --encoding=UTF-8 acbd3e652a3e3d88096c5e45febd382756bc31f9..ec0d61ef4b3a6eb1413444d42c210a99bcaa615f packages/api/.env [14ms]

Are the same sha values acbd3e652a3e3d88096c5e45febd382756bc31f9..ec0d61ef4b3a6eb1413444d42c210a99bcaa615f repeating or are they actually changing?

It's important to note: You may see the same sha pair repeat once or twice and in reverse order, so it's important for us to know if the output log over 10 minutes is showing the same sha pairs or going through different pairs; each sha represents a branch...

Lastly if it's possible to get a copy of those output logs, that would be really useful.

[Steakeye]

Hi @wsrast,

Are you able to confirm with us that the sha values are always the same for every single Git log?

It's just that so far we've not been able to reproduce that and therefore it would spur another line of investigation from us, while at the moment we think it's an issue related to the number of active branches, which we now have a ticket for in our backlog.

We will close this issue, assuming it's now being tracked in our development pipeline unless we receive confirmation about the identical sha values all the way down.

Thanks, Andrew

[Ygnys]

Closing the issue because it needs more information and has not had recent activity. Please re-open the issue if more details can be provided. Thanks!