1. 10
  1.  

  2. 7

    So the only real pro-arguments here are “it looks cool and my tools sometimes need it”?

    1. 4

      my tools sometimes need it

      Seems like a pretty useful argument. What’s the cost?

      1. 1

        OP here (of the blog post). “git merge-base” behaves better with this approach if the commits you supply happen to span orphan branches.

        Probably my tool (and git merge-base) almost never need it. I feel a bit as if I’m Randall Munroe keeping velociraptor repellent spray near my person at all times just in case…

      2. 5

        I’ve never actually seen an orphan branch in the wild.

        I use them for Github’s gh-pages branches. However, the official documentation suggests to branch of master and delete everything.

        I also work in a repo with three roots. It was different repos, which got merged later.

        1. 3

          linux is also made of three roots: the original import from BK, the btrfs tree import, and the graylog tree import.

          1. 1

            In Myrddin, I’ve found it’s a nice model to develop libraries outside of the main repo, and when I’ve decided that they’re general and useful enough, to rewrite them such that files end up in the appropriate subdirectories, and then pull them in.

          2. 1

            I have occassionally used just a .gitignore or an empty README to get a (near) empty root when I feel that I need that. This would usually be if I started a project that I wanted a sanity check on my initial approach, so made all the commits on a with a PR into an empty master branch.

            1. 1

              If it’s true that we should always do it then git init would give us it for free.