Subgit initial import to repos configured with non-master default branch

SubGit
#1

scenario:

  1. create empty bare repository with “main” as the primary branch,
  2. subgit configure + subgit install or subgit import,
  3. repos.git/refs is still “refs/heads/main”

If you clone this repository, it will fetch everything but then complain

warning: remote HEAD refers to nonexistent ref, unable to checkout.

Workaround:

Hand-edit/replace the file HEAD in the top of the repository:

  • look in the $repo/refs/heads folder for the name of your trunk branch, i.e. trunk or Trunk
  • change $repo/HEAD to have that name instead of main or master

Our trunk branch is called “Trunk” so my $repo/HEAD now reads:

ref: refs/heads/Trunk
#2

Hi Oliver,

thank you for sharing this approach!

Do I understand correctly that the intent is to use the main or Trunk branch instead of master in the Git repository? If so, then the first step of creating a bare repository seems redundant for me as SubGit is able to create such a repository at the import or install beginning. Also, it would worth to mentions that the SVN trunk should be mapped to Trunk in Git:

[svn]
    trunk = trunk:refs/heads/Trunk

But good point about editing HEAD, we’ll discuss it internally to change the behaviour in the next SubGit release.

#3

Hi Ildar,

This was to import a repository under an SCM (GitLab in this specific case), so pre-creating the repository was a requirement.

Our CTO has a thing for folders being Capitalized, so the actual config is:

[svn]
    trunk = Trunk:refs/heads/Trunk
    branches = Branches/*:refs/heads/svn/branch/*
    branches = Tags/*:refs/heads/svn/tag/*

This lets my users do the request-based workflow in GitLab without contaminating svn, and guarantees that any cross-over to an actual svn-mirrored branch has to be extremely deliberate and specific :)

I mention this because it worked beautifully when I did my first fast-forward merge from a non-svn branch.

Exact workflow:

  • cut git branch,
  • develop, review, approve,
  • manual squash to tidy up details, organize the commit for prod,
  • scm rebase → auto rerun tests,
  • automatically fastforward merged,
  • automatically delete pull-request branch,

I imagined it either wouldn’t work at all, or the entire commit would appear as a single merge transaction. But yay, tmate just Did The Right Thing!

Worked for me in Gitlab with Subgit and Bitbucket with SVN Mirror, and worked wonderfully.

A+ magic :)