Slashes in branch names

[ismay]

See slack conversation here: https://dhis2.slack.com/archives/C0BP0RABF/p1588249435318600

I've run into an issue with git for repos that use slashes in their branch names. We do that in some areas and it creates a conflict in some cases. In my case, I had:

• A branch called test
• Was attempting to pull a branch called test/layer-context-issue-demo

This creates an error in git as it'll have .git/refs/remotes/origin/test and then can't create refs/remotes/origin/test/layer-context-issue-demo as the former already exists.

It seems that git had already created the test file and was attempting to create a directory with the same name, which doesn't work (at least, not on *nix). So we can either have the test namespace for git branches, or a test branch, but not both.

I propose we just don't use slashes in branch names. Coordinating namespaces vs branch names seems too much effort, when compared to the (minor) benefit of using slashes in branch names.

Related SO answers:

• https://stackoverflow.com/a/2527452
• https://stackoverflow.com/a/2527436

[HendrikThePendric]

For years I have been using slashes and I've never had a problem, until I encountered the same issue @ismay mentions above, a while ago. I would be fine with no longer using slashes in my branch names, even though I'll loose the nice folder structure in my git gui.

Alternatively we could say that all conventional commit types are "reserved namespaces", but as @ismay says, I don't think the additional mental overhead justifies the benefits.

[varl]

While the Git internal reasons for why this happens are perfectly logical, it is a gotcha moment when it happens, as it is most likely to happen when working with a remote and the user unexpectedly runs into some internal Git mechanics.

Git stores the commit pointing to the tip of the branch in .git/refs. There may be remotes configured, and they end up under remotes, there's heads which contains references to the HEAD of each branch locally. The examples use refs/head for simplicity. The principles apply to refs/remotes as well.

git checkout -b foo creates a file named foo under .git/refs/heads with a commit hash as content.

$ git checkout -b foo
Switched to a new branch 'foo'

$ ls -l --format=single-column .git/refs/heads
master
foo

$ cat .git/refs/heads/foo
829375110d4a7850418d8eb1337841228d6e0cb3

git checkout -b foo/bar creates a foo directory under .git/refs/heads and creates a file under the foo directory named bar with a commit hash as content.

$ git checkout -b foo/bar
Switched to a new branch 'foo/bar'

$ ls -l --format=single-column .git/refs/heads
master
foo/

$ ls .git/refs/heads/foo
bar

$ cat .git/refs/heads/foo/bar
829375110d4a7850418d8eb1337841228d6e0cb3

Since Git uses standard files and directories under the hood, the rules of those apply as well. That usually means that it is not possible to create a file with the same name as a directory or vice-versa.

$ mkdir foo
$ echo "yikes" > foo
bash: foo: Is a directory

$ touch bar
$ mkdir bar
mkdir: cannot create directory 'bar'

Due to nature of this gotcha being the fact that two files cannot have the same name on an OS level, I do not believe we should outlaw either as it comes down to how the naming is used within a user/team's workflow.

For example, multiple branches targeting the same JIRA issue could be grouped with dhis2-1234/feature-dance-dance and dhis2-1234/bug-stopped-dancing, and perhaps some teams want to organize their work that way. Disallowing slashes is more heavy handed than I would like us to be.

To reduce the chance of conflicts, we shouldn't encourage single-word branch names. Common single words, such as "test" have a higher probability of getting hit by this gotcha, and if it occurs every few years it's a minor annoyance when it happens vs. restricting our options to choosing our own workflows.

We do need to protect some branches across all our repos (alpha, next, etc.) and could extend that to the conventional commit scopes (fix, feat, test) as well.