10 ms·
The problem with that argument is that it would prevent _any_ improvements to git that don't correspond to outdated documentation. You could just as well argue
by a2800276 4y ago
The problem with that argument is that it would prevent _any_ improvements to git that don't correspond to outdated documentation.
You could just as well argue that the changed name of the default branch is one of very many things that make git difficult for beginners to learn and having bumped into it early taught a valuable lesson that branch names in git are arbitrary.
Something that took me a longer than I care to admit to figure out.
- ParetoOptimal 4y ago> taught a valuable lesson that branch names in git are arbitrary. Agreed. Seeing this in the tutorial (if it hasn't already been updated as such) would be great: > Branch names are arbitrary, but for convenience a default of 'main' is provided. There's nothing special about 'main'. Of course I'd double check they really are arbitrary for all contexts before adding the above since I'm not 100% confident it's true.
- a2800276 4y agoIt's arbitrary save that a default value (i.e. "master") exists that is used if none is provided to 'git init' when the repo is first created. That default name is configurable, e.g. to 'trunk' if you like things confusing: `$ git config --global init.defaultBranch trunk` The name 'origin' for the remote repository that you originally cloned from is likewise arbitrary. There is nothing magical about `git push origin master`. You could name your remote "my_github_account" and do `git push my_github_account trunk`. This knowledge becomes essential if you're synch'ing with several remote repos. OTOH, knowing that these are arbitrary names and not part of the command make it more obvious that it's _possible_ to have multiple remotes in the first place. But it comes at the cost of making life more difficult for authors of tutorials designed to get people to memorize difficult git commands without understand what they do.
- ToValueFunfetti 4y agoPart of the argument identifies a harm to making changes to git, which is true for any changes to git that break existing documentation. I would hope that git maintainers are considering that when deciding about making any changes. But the other part of the argument is that the benefit is too small (or nonexistant) to outweigh the harm, which is not true in all cases.