GitHub, f ck your name change

• repositories

  9 - -

I fight against this useless political correctness with my own, albeit invisible, rebellion:

I've set repository default branch to `master` [1] on Github.

I've created init.templateDir with HEAD set to `master` [2]

That way, whenever I init a new repo, either locally or via Github, the default branch is master, not main.

[1] https://github.com/settings/repositories

• Git

  287 50,099 10.0 C

  Git Source Code Mirror - This is a publish-only repository but pull requests can be turned into patches to the mailing list via GitGitGadget (https://gitgitgadget.github.io/). Please follow Documentation/SubmittingPatches procedure for any of your improvements.

  

> init: provide useful advice about init.defaultBranch

> To give ample warning for users wishing to override Git's the fall-back for an unconfigured `init.defaultBranch` (in case we decide to change it in a future Git version), let's introduce some advice that is shown upon `git init` when that value is not set.

https://github.com/git/git/commit/675704c74dd4476f455bfa91e7...

    git tag --contains 675704c74dd4476f455bfa91e72eb9e163317c10 | grep -v rc

• InfluxDB

  www.influxdata.com featured

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• SwiftLint

  23 18,322 9.4 Swift

  A tool to enforce Swift style and conventions.

  

I think we've reached the peak of absurdity, when a linting utility adds an enabled by default inclusive language rule that breaks people's builds for daring to use racist terms like "MasterViewController" or "MasterCard".

https://github.com/realm/SwiftLint/pull/3243

• renaming

  36 2,368 0.0

  Discontinued Guidance for changing the default branch name for GitHub repositories

  

Well 'main' is a more intuitive & UX friendly name than 'master' which new devs are going to intuitively relate to as it's commonly used to refer to the 'main thing', e.g. main road, main course, etc. I can't recall the last time I used 'Master' as a synonym to 'main' outside of technology (as a Redis Client author I still deal with Master nomenclature a bit). There is 'Masters degree' but that has to do with Mastery knowledge rather than 'Master copy'.

As a library author I often deprecate & rename new APIs when I can think of a more appropriate and a descriptive name to replace a misleading name. I put a lot of weight into the name of symbols as it basically has the largest bearing in understanding its functionality & purpose. This is effectively what GitHub is doing, deprecating 'master' in favor of 'main' for new repos, which I don't see a problem with as it's looking pretty clear that all new technology is moving away from master/slave terminology - I don't see why Software needs to force usage of old legacy names if they're able to deprecate it and move to new more appropriate naming without breaking existing repos.

This change hasn't broken any of my 100+ existing repos, GitHub is only changing the default branch to 'main' for new repos & have implemented a bunch of work behind the scenes to reduce the friction for orgs & users who also wish to rename their existing mater branches [1]. I really don't understand the hate this effort to more modern & inclusive naming is inciting, if you want to criticize GitHub for their lack of action in other areas, criticize that instead.

[1] https://github.com/github/renaming#renaming-existing-branche...

• los-opinionated-git-tools

  2 5 0.0 Shell

  A collection of Very Opinionated Git tools and aliases to aid my Git workflow. Will these aid yours?

I've had to deal with projects where the "main" branch was named: master, main, blead.

I almost never "name" that "main" branch, thanks to commands and aliases.

When I want to pull (and rebase) to the "main" branch, I run "git prom". When I want to check out the "main" branch, I "git com". What actually happens depends on what the project's "main" branch is. If a project later moves to a "live" branch, I'll just update the "git-main" script to detect it ahead of the rest, and off I go.

https://github.com/mfontani/los-opinionated-git-tools/blob/m... is less than ten lines of bash.

git-com is really just: git checkout "$(git main)"

git-prom is really just: git pull --rebase origin "$(git main)"

I'm not particularly sold on "main" vs "master" being an important thing, but if it's important to some I at least want to ensure I don't get frustrated when interacting with a project which uses it. With the above aliases and functions and programs, I don't care anymore.

main, master, blead... call it whatever.

• SaaSHub

  www.saashub.com featured

  SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

  

Suggest a related project