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

[pcc-dickek]

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

[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 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.

[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.