Installing asdf via Homebrew now requires souring from a different path.
This same issue was recently fixed in thoughbot/laptop by @cpytel, and so I've copied the changes from this commit:
aa3a84e15e
Before, we dropped our custom "Ag" command in favour of the version with
fzf.vim. Unfortunately, this change also removed the handy "\" shortcut
to activate Silver Searcher. We added the shortcut back to the Vim
configuration.
* I recently setup my M1 mac and had a similar problem to this issue
reported here https://github.com/thoughtbot/dotfiles/issues/702
The fix for me was to do what homebrew says after the install which is
to add to or create a .zprofile with the following command
`eval "$(/opt/homebrew/bin/brew shellenv)"`
* Introduce a zprofile with commands to eval homebrew on mac or linux if
the homebrew directory exists
* The Ag command from fzf.vim that loads the fzf shell does seem
more useful than than the command being defined here. The one downside
I see though is that `:Ag some_search` will open the fzf shell rather than
populating the vim quickfix window, however you can just select all
files in the fzf shell with alt-a and click enter to add all the files
in the fzf shell to a quickfix window.
* Remove custom :Ag command vim in favor of :Ag command defined in
fzf.vim
* Closes#682
Why:
----
Whenever we run a command to use a certain port and we get an error that
the port is in use, we have can either:
1. Clear the port so our new process can use it
2. Try and use a new port for the command we just typed
In order to make a decision about it, we need information on what is
running on that port, so we can determine if we want to stop that
process or if it's important enough to keep.
What:
----
Two new commands are added to /bin. One to output
information about the process using a provided port:
``` bash
$ whats-in-port 3000
$ COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
$ ruby 25583 root 11u IPv4 0xee20607697a79bf7 0t0 TCP *:irdmi (LISTEN)
```
This command uses the [lsof] program to get information of the process
utilising that port.
And another one making use of the previous utility to kill the process
running in that port:
``` bash
$ clear-port 3000
```
[lsof]: https://linux.die.net/man/8/lsof
Co-authored-by: Mike Burns <mburns@thoughtbot.com>
Co-authored-by: Edward Loveall <edward@thoughtbot.com>
i removed configs so that one can run ctags -R in a rails app without
the program exiting badly. i verified that Elixir definitions exist in
ctags itself (in
~/Library/Caches/Homebrew/universal-ctags--git/optlib/elixir.ctags for
me).
* Don't gitignore tags/ directories
For example, the [rails/rails][] project has an entire directory of
classes with `tags` in the name, which hides it from search tools (like
[`ag` The Silver Searcher][ag]) and prevents committing changes or
introducing new files.
Support for ignoring [files named `tags`][git_template/hooks], but
including _directories_ named `tags/` was originally introduced in
[a99fbb0][], but was subsequently broken when the [negative `!tags/`
pattern declaration][] was moved _above_ the `tags` line that it
negated.
Instead of fighting the ignore patterns, this commit removes both lines.
We currently ignore the contents of the [`.git/` directory][.git/],
which is where [we store the `tags` file generated in our
`git_template/hooks/ctags` command][git_template/hooks], so we should be
covered without explicit declarations.
[rails/rails]: https://github.com/rails/rails/tree/master/actionview/lib/action_view/helpers/tags
[ag]: https://github.com/ggreer/the_silver_searcher/tree/2.2.0#whats-so-great-about-ag
[a99fbb0]: a99fbb0f57
[gitignore-pattern]: https://git-scm.com/docs/gitignore#_pattern_format
[git_template/hooks]: 56d614f806/git_template/hooks/ctags (L10)
[.git/]: 56d614f806/gitignore (L8)
* Ignore `tags` file
In case a `tags` file is declared outside `.git/tags`, continue to
ignore it, while still supporting `tags/` directories.
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.
In f252ba4 we lost some of the functionality of `git-up`. This change
brings back rebasing against the origin's reference and not the local
reference of the main branch. We also explicitly fetch from `origin` now
to be sure we're current before rebasing.
Close#671
In [a previous commit], we removed the fetching of the "origin" remote
from the "up" Git function. With this change, developers had to fetch
manually before rebasing their branch. We added the fetch back into the
"up" Git function.
[a previous commit]: f252ba46d1 (diff-b973d5fb5d66981ace5c069881095355)
There's been a recent movement to rename the "master" branch in git
repositories to "main" to avoid to potentially problematic word
"master". Our `merge-branch` script was hard coded to "master". This PR
makes it possible to pass in the name of the branch you wish to merge
to. I've defaulted it to "master" for now, but I expect in time this
will change.
Our team is renaming the base branch of our application from `master` to
`trunk`. I had held off on doing this in the past because `git up -i`
has become such an huge muscle memory thing and I didn't want a script
to only work on some of my frequent repositories.
This [trick from Stack Overflow](https://stackoverflow.com/a/49384283/1190970)
shows how to grab the name of the primary branch for a remote branch without an
expensive git operation. It'll allow a rebase against the tip of the primary
remote branch regardless of its name.
asdf has a very useful configuration setting called
`legacy_version_file`. When it is set to `yes`, asdf will read the
version files used by other version managers (e.g. `.ruby-version`) in
addition to asdf's own `.tool-versions` file. This makes the migration
to asdf much smoother, as many projects only specify these 'legacy'
dotfiles for versioning.
Documentation: https://asdf-vm.com/#/core-configuration?id=homeasdfrc
Closes https://github.com/thoughtbot/dotfiles/issues/654
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
Summary:
This change addresses an error that occurs when we've instructed vim to
reference the wrong path for an existing FZF executable.
Additional Details:
In the previous approach, when checking if FZF has already been
installed, we make the assumption that if FZF is `executable` it was
installed via Homebrew. Then, based on that assumption, we set vim's
`runtimepath` to reference the directory where Homebrew creates symlinks
for installed packages (`/user/local/opt`).
Because of this assumption, anyone that has FZF installed in a different
directory, and available as an executable in their $PATH, attempting to
use FZF within vim will result in an error. The reason vim errors is
because `Plug` has instructed vim's `runtimepath` to look in the wrong
location for FZF (in this case, we told vim to look for FZF within
`/user/local/opt` when the FZF executable lives somewhere else).
The revised approach still attempts to find an existing FZF package
before proceeding with installing FZF.
Summary:
Using CtrlP has proven to be slower and has fewer features. We've been
switching over to FZF on a frequent enough basis that it feels
appropriate to make FZF the new default for fuzzy searching.
By swapping out Ctrlp in favor of FZF, this should not break anyone's
fuzzy search but it will replace the tool that executes the search.
Co-authored-by: Chris Toomey <chris@ctoomey.com>
from man
>If the session name is prefixed with an ‘=’, only an exact match is accepted (so ‘=mysess’ will only match exactly ‘mysess’, not ‘mysession’).
