Git 2.28 now has a setting to change the default branch for new
repositories. This sets init.defaultBranch to main and removes the HEAD
file from the git template.
The HEAD file will need to be removed from ~/.git_template manually, as
rcup does not remove deleted files.
https://github.blog/2020-07-27-highlights-from-git-2-28/#introducing-init-defaultbranch
New Git repositories start out without any branches, but the HEAD
reference points to "master" by default. This means that the first
commit will create a master branch.
This change adds a HEAD file to the Git template with a different ref.
This means that new repositories will commit to a "main" branch by
default instead.
The HEAD file is added to COPY_ALWAYS, because Git's HEAD must be a
regular file and not a symbolic link.
People may wish to configure a `commit-msg` hook in their local
dotfiles.
This allows them to do so by adding a [`commit-msg` git hook][1] that
checks for the presence of a local `commit-msg` hook, and runs it if
present. This hook follows the existing pattern we use for other git
hooks.
[1]: https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks
**Bring executables into better shellcheck compliance**
While evaluating linting and testing options for our shell
configuration, a run of Shellcheck against our executables turned up
some places where we could use more consistent syntax across our
executables, such as always using a shebang or quoting `$HOME` when we
build up a larger directory.
**Update syntax for zsh functions and completions**
A few changes found while linting zsh configs with shellcheck:
* thoughtbot's [style guide] [guide] calls for `$(..)` over backticks
when capturing command output
* use `-gt` to test array length in arguments
[guide]: https://github.com/thoughtbot/guides/tree/master/best-practices
Xcode >=6.0.1 throws an error when creating a new git-tracked project
without an 'exclude' file. Created the exclude file to correspond to
the existing gitignore file.
More info about this file:
http://seejohncode.com/2012/02/29/git-info-exclude
For users who had not overridden the `pre-commit` or
`prepare-commit-msg` Git hooks,
they would see `git commit` hang,
with nothing happening.
The command would exit without going to their editor.
The bug was introduced in d7f194f94e
and the fix is to return a 0 exit code when the override is not present.
The `pre-commit` and `prepare-commit-msg` git hooks can be used
for some interesting things such as linting files.
For example, I need to format, vet, and lint Go files:
https://github.com/croaky/dotfiles/blob/master/git_template.local/hooks/pre-commithttps://github.com/croaky/dotfiles/blob/master/git_template.local/hooks/prepare-commit-msg
We've rejected Go-related pull requests to thoughtbot/dotfiles
due to not doing enough "official" Go work at the company.
This change helps me start with `.local` for now,
and then promote to "upstream" (thoughtbot/dotfiles) at some point
in the future if we do more "official" Go work.
I'm a believer in having linting done at VCS "commit time", either
locally in a pre-commit so I have a chance to fix things and not both my
teammates with linting issues, or at post-commit time via Hound comments
(also automated, but opportunity to ignore).
I've tried adding linting libraries to my editor, and found them too
slow, at least for Ruby. I've limited "editor-time" checking to just
syntax checking via Syntastic.
The downsides I see to adding linting to the test suite are:
* Style violations are not functional failures and logically shouldn't
fail a build.
* Adding code coverage, linting, etc. to a test suite slows down the
build.
* I only need to lint my diff (the commit), not the whole codebase, when I
make changes.
* Style violations should not prevent a user-facing, production deploy.
* Adding linting to the test suite can slow that process down
unnecessarily, particularly in continuous integration setups.
I see the appeal of linting in the test suite, particularly for
greenfield apps where we have total control, but I don't think it's a
practice that we can universally apply to our client projects who have
different deploy setups and existing codebases. So, I prefer the git
hooks + Hound approach as a pragmatic middle ground.
