Unable to fetch some branches unless set to "use a git executable"

[pcc-dickek]

GB will not show some branches that exist on the remote unless I set git authentication to "use a git executable".
This breaks on either SSH key option. I haven't tried the "credentials helper" method.

When set to use an SSH key, I can fetch these branches with git fetch manually from the git cli, but they disappear again the next time GB fetches.

Out of 178 branches in the repo I'm working on only 2 have this issue, and there doesn't seem to be anything out of the ordinary about them. One has been merged to the default branch, the other is unmerged.

If anyone can point me in the right direction to do some debugging I can try to see what's up, since I don't actually know how this could be reproduced. The logs do not show any obvious errors.

System: macOS Sonoma 14.4.1 (Apple Silicon)
Git: 2.39.3 (Apple Git-146)
GitButler: 0.11.7
Remote: Bitbucket v8.9.9

[Byron]

Thanks for reporting! If I am not mistaken, the code responsible for fetching is right here. It uses the same refspec in both cases, i.e. when using the Git executable, or when using git2 in case of the SSH based authentication.

As the fetching doesn't list any refs, I presume refs are later traversed to populate the UI and it's unclear to me how that traversal could be different. Something that comes to mind is that for some reason, the 2 branches that seem missing are actually not present in the repository anymore.

Thus, could you clarify what disappear means? Are they actually gone from the local repository? This would be my expectation actually, as otherwise it wouldn't make sense that previously fetched and locally present branches aren't listed anymore.

Thanks for your help.

[pcc-dickek]

By disappear I mean they were listed in the following places after a vanilla checkout or after fetching using an executable in gitbutler, but are no longer listed after fetching with an existing or generated key through gitbutler.

• gitbutler's UI,
• git branch --remote/--all
• ls .git/refs/remotes/origin
• cat .git/packed-refs

They are still present on the remote when looking at bitbucket's UI, or when cloning the repo with vanilla git.

But also, upon reviewing this I just noticed a clue I'd missed before, and now have a way to reproduce this. All of the affected branches are named Task/some-branch (capital T) whereas most branches would be named task/some-other-branch. So this looks like a bug arising from developers randomly doing casing wrong. All of us are either on windows or macos; case-insensitive and case-insensitive by default, respectively.

I realize git is case-sensitive, but gitbutler should probably still follow how git handles this on case-insensitive systems, rather than ignore the branches.

So, to reproduce:

1. set up a remote (plain SSH remote, to remove more variables)
2. clone the remote in two places, one we'll use vanilla git, the other gitbutler
3. in the vanilla git repo, do an initial commit on branch main
4. set up a branch task/good-branch, and push it
5. switch to the gitbutler instance of this repo, pull these changes
6. set up gitbutler on this repo with an SSH key
7. in the vanilla repo, create a branch Task/bad-branch, and push it
8. try fetching it gitbutler - the branch won't show up
9. switch gitbutler to use the local git executable and fetch again - the branch is now displayed
10. switch back to using an SSH key and fetch again - the branch is removed

When using vanilla git or gitbutler set to use the git executable, this case issue seems to be handled by placing the branch with odd casing in the existing directory.
So Task/bad-branch on the filesystem becomes .git/refs/remotes/origin/task/bad-branch.

All that said, it looks like this is probably an upstream issue, maybe with libgit2.

[Byron]

Thanks so much for researching this! Indeed, I didn't find any evidence that GitButler does anything special when fetching, it's all handled by libgit2, so I agree that it's probably some obscure bug there. Maybe gitoxide can do better there, when the time comes.