It doesn't load any information

[eniel-rodriguez]

Please share:

1) Your operating system Ubuntu 22.04 2) A screenshot (if possible) 3) The contents of the output panel (found at the bottom of VSCode) for the "Interactive Git Log" channel.

[track] ClientConnection  
establish client connection for /home/user/projects/project
Using cached repo info
Fetching commits...
Fetching commits...
Fetching commits...
Fetching commits...

[tnesbitt210]

Thanks for the report @eniel-rodriguez . I'll add some more logging soon, and will reach back out when it's ready. Hopefully that'll help us pinpoint the issue.

Long load times might be expected for repos where the branch you're working on has diverged very far from the primary remote branch (the "primary remote branch" is usually origin/main or origin/master). To determine if this is the case, try checking out the branch that you mainly work on (skip this step if you're already on that branch) and running git rev-list --count origin/master..HEAD (or origin/main, or what ever the name of your primary remote branch is). Could you let me know what the output is?

If the number is high (high double digits or more), you might try pushing to origin/master or origin/main, and seeing if the long load times still occur after that.

[eniel-rodriguez]

Hi! The output to the command is 0.

[tnesbitt210]

Thanks @eniel-rodriguez . I just pushed version 0.1.49, which logs some debug info if the commit graph doesn't load quickly.

If you could update to 0.1.49, try to load the extension for 30 seconds or so, and send me the contents of the output channel after that, that'd be very helpful!

You should see an event "FetchCommitsDebugInfo", which will give me some info about where the program is getting stuck.

[eniel-rodriguez]

Hi! I just tried, updated the extension, even restarted VSCode, but I don't see relevant information:

Debug Info:

commitTreesLength: 0

uncommittedChangesLength: 1

outputChannelContents:

Setup analytics, session:  ee6b7c0d-92d8-446f-b718-5af9cbbd7f251718869315299
Operating System: linux 6.5.0-41-generic
IGL Version: 0.1.49
Using cached repo info
[track] ClientConnection  
establish client connection for /home/user/projects/project
Using cached repo info
Fetching commits...
Fetching commits...
Fetching commits...
Fetching commits...
Fetching commits...
Fetching commits...
Fetching commits...

Interestingly it only happens with projects that are on a private Git server, I just tried it with a project that is on Bitbucket and it works fine:

Debug Info:

commitTreesLength: 1

uncommittedChangesLength: 1

outputChannelContents:

Setup analytics, session:  4aeb474a-15e6-4924-9a3f-debc108b7c701718869640072
Operating System: linux 6.5.0-41-generic
IGL Version: 0.1.49
Using cached repo info
[track] ClientConnection  
establish client connection for /home/user/projects/project_on_bb
Using cached repo info
Fetching commits...
Loading commits success
Sending commits to client
Fetching commits...
[track] InitialFetchSmartlogCommits  {"numCommits":1,"numPublicCommits":1,"numBranches":1,"watchmanInstalled":false,"brewInstalled":false,"msToFetch":5207}
[track] CommitTreesLoaded  
Loading commits success
Sending commits to client
Fetching commits...
Loading commits success
Sending commits to client
Fetching commits...
Loading commits success
Sending commits to client
Fetching commits...
Loading commits success
Sending commits to client
Fetching commits...
Loading commits success
Sending commits to client

[tnesbitt210]

Interesting... that's a smart hypothesis!

I took a very quick look at the code just now, and I think the only explanation I can think of that would explain the failure could be that the following command is failing, or returning an unexpected output

git ls-remote --symref origin HEAD

(if your remote is named something other than "origin", replace "origin" with what ever the name of the remote is)

The program then looks at the output of this command and tries to find a string like refs/heads/branchname (usually branchname is "main" or "master"). The program considers what ever branch is outputted from this command to be the "primary" branch that all other branches fork off of.

Could you let me know what happens if you try to run this command locally? I've also updated v0.1.50 to display an error more explicitly in the UI if there's a failure with this command.

In any case, I'll look more deeply later to:

• See if I can recreate a "private Git server" setup to debug with (please let me know if you have any instructions on how to create an environment similar to what you have)
• See if there's any other potential causes
• Maybe add more logging

[eniel-rodriguez]

For projects that are on the private or custom Git server, the output of the command, on any branch, is: f47e1957b8b41495dd22d95fd8545720b2bc7cf5 HEAD

On the other hand, in the projects that are in Bitbucket the output is:

ref: refs/heads/master HEAD
a5383458c3b163834cecc8331ccdca3d82e7d19b HEAD

[tnesbitt210]

@eniel-rodriguez that would definitely explain the problem. Thanks so much for the info - I'm keen to find a fix.

Is the "custom" git server hosted on github? If not, is it another website? (I'd like to try to reproduce your setup, so any info you can share would be helpful).

Do you know what the name of the primary remote branch is (origin/main? origin/master?).

Thanks!

[tnesbitt210]

I've also pushed version 0.1.52, which uses a fallback if git ls-remote --symref origin HEAD fails.

Would you mind updating to version 0.1.52, and letting me know if the issue still persists? Thanks!

[eniel-rodriguez]

It's an on-premises server, I don't know much about it, my access is quite limited.
The name of the primary remote branch is origin/master.

I updated to the latest version and it works!
Thank you so much!