Feature: Default branch on git repos

[dwarburt]

I'm working with a git repository in keybase which has a default branch that is not master. It would be handy if I could specify the default branch for the repo with the keybase command, like: keybase git set-default <reponame> <branchname> or something. Similar to the way default branches work in GitHub: https://help.github.com/en/github/administering-a-repository/setting-the-default-branch

[jamesboehmer]

I'd like to add that I think this also creates a buggy experience that requires a hacky workaround. If you push your local privatedotfiles repo with a default main branch to a bare keybase encrypted repo, and then clone it elsewhere, you get this warning:

Cloning into 'privatedotfiles'...
Initializing Keybase... done.
Syncing with Keybase... done.
Counting: 141.08 KB... done.
Cryptographic cloning: (100.00%) 141.08/141.08 KB... done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.

When you change into the cloned repo directory, the directory only contains the .git index with no HEAD symbolic ref, and running git checkout main gives the error fatal: not a git repository (or any of the parent directories): .git. Adding a HEAD symbolic ref doesn't work. The only way to get the branch is to use git clone -b main keybase://... so that the branch is checked out immediately. Even then, git ls-remote shows:

ff028ae6d8b832f031bb87b98b24fe0c1431ac5d	refs/heads/main
0000000000000000000000000000000000000000	HEAD

Contrast that to a bare repo on an SSH host. When I can clone the repo, I still get the nonexistent ref warning, however git checkout main works fine. I can also clone seamlessly with git clone -b main. I can also alter the bare repo with git symbolc-ref HEAD refs/heads/main, and then git clone works as expected.

It's that last step that I can't find a way to do with the keybase encrypted repo.

[Delivator]

Any updates or workarounds on this? Is there a way change the remote HEAD branch?

[jbuckner]

Thanks for posting this. I renamed my master branch to main and re-cloned my repo and thought something broke. I'm seeing the same that @jamesboehmer posted. I renamed main back to master and now it's working properly again, but that is kind of a scary thing to see.

[silasdavis]

I can confirm adding back a master branch makes the repo cloneable. Clearly master is hardcoded somewhere. Makes it difficult to trust keybase repos here.

[JoshMock]

Using anything but master as the default branch still causes this error, and git clone -b main keybase://... is currently the only workaround. And the repo's files are not viewable in the Keybase desktop UI, either. It just shows as an empty directory, which is kind of terrifying if you don't know what's going on.

[epipheus]

c'mon keybase; can't you prioritize honoring a git branch -M main without obscene backflips by your community? This is the norm now for most dev teams.

[epipheus]

I'm lost here. main is most people's default now. why wouldn't keybase allow us to show any branch we want as default or honor git branch -M. what gives?

[kg4zow]

Keybase git repos are stored under a "hidden" directory in the KBFS TLF (top-level folder) of the user or team containing the repo.

Repo	Directory
keybase://private/jms1/xyzzy	/keybase/private/jms1/.kbfs_git/xyzzy
keybase://team/dummy/xyzzy	/keybase/team/dummy/.kbfs_git/xyzzy

You can change what the "server" thinks the primary branch's name is by manually editing the HEAD file there.

$ cd /keybase/private/jms1/.kbfs_git/xyzzy/
$ cat HEAD
ref: refs/heads/master
$ echo 'ref: refs/heads/main' > HEAD

After doing this, a new git clone keybase://private/jms1/xyzzy command will clone the repo and check out the main branch automatically.

At first I thought it would make sense for the keybase git create command to have an option to specify the primary branch name, however it turns out the repo's "hidden directory" doesn't actually contain anything useful until the first commit is pushed. It looks like the code was written with the assumption that new repos will always use refs/heads/master as the primary branch name (see the newBrowser function in go/kbfs/libgit/browser.go for details).

[magJ]

@kg4zow your workaround partially works, however it seems that the functionality of the UI is still broken.

The UI seems to use .kbfs_autogit instead of .kbfs_git. Which seems to also default to master, but has no .git directory to edit.

[kg4zow]

TLF is "top-level folder", such as /keybase/private/USER_NAME or /keybase/team/TEAM_NAME. (You may want to remember this term, you will see it in the Keybase documentation.)

TLF/.kbfs_git/RRR/ contains the "bare repo" for the RRR repo, which is all of the control files making up every branch, tag, commit, and the commit contents. This is almost identical to what you would see in the .git/ directory in a cloned copy of the repo.

TLF/.kbfs_autogit/RRR/ contains what would be the contents of the RRR repo's "primary" branch, if the repo were cloned somewhere. As has been mentioned a few times above, the primary branch appears to be hard-coded as "master" in several places in the code. This is one of those places.

BUT.

TLF/.kbfs_autogit/RRR/.kbfs_autogit_branch_BBB/ "contains" what would be the contents of the RRR repo's BBB branch, if that were cloned somewhere.

As an example, I just did the following:

mkdir /tmp/xyzzy
cd /tmp/xyzzy
git init -b master
echo 'this is the master branch' > info.txt
git add info.txt
git commit -m 'initial commit, master branch'
git checkout -b main
echo 'this is the main branch' > info.txt
git add info.txt
git commit -m 'adding main branch'
keybase git create xyzzy
git remote add origin keybase://private/jms1/xyzzy
git push -u origin main
git push --all

Then, to examine what happened "under the covers" ...

$ ls /keybase/private/jms1/.kbfs_git/xyzzy/
HEAD		config		kbfs_config	objects		packed-refs	refs
$ cat /keybase/private/jms1/.kbfs_autogit/xyzzy/info.txt
this is the master branch
$ cat /keybase/private/jms1/.kbfs_autogit/xyzzy/.kbfs_autogit_branch_main/info.txt
this is the main branch

As for the GUI client, I think the issue there is that they just didn't write in a way to select a branch, so your only choice is the "primary" (aka master) branch. At least, if there is a way to choose a branch, I couldn't find it.

[jms1voalte]

Adding a comment to "refresh" the issue, and so my work account's email gets notifications about this. (I'm the same human as the @kg4zow user.)