git has always(?) allowed for the additional configuration files to be unconditionally included:
[include] path = path/to/gitconfig
Each individual git repo has always had the ability to maintain its own
.git/config. However, sometimes on our systems we also
have certain locations where we store multiple git projects, which may need
different configuration from the global, but still common across that
Since ... well, for the last year or two at least, git has allowed for the conditional inclusion of configuration files.
For example, I contribute to F/OSS projects using one email address, which
lives in my global git config (
~/.config/git/config, in my case). However,
for work projects, I want to use my work email everywhere — and accidentally
pushing w/my personal email address is just embarrassing. All of my work
projects live under a certain directory, so I can tell git that if a given
repository's gitdir lives under
~/work, it should also load an additional
[includeIf "gitdir:~/work/"] path = ~/work/gitconfig
...and in there, I can set
; this is ~/work/gitconfig [user] email = email@example.com
In this way, I do not need to remember to change the email address of any
repos I clone under
~/work to my work address. This is especially useful as
I not infrequently find myself forking and submitting bugfix PR/MR's to
upstream, and if I do that for
$work then I want to be using my work email
See also the "Includes"
and "Conditional Includes" sections of the
A while back, I wrote about
"useful git defaults". This is a tricky subject, as a sufficiently aged
~/.gitconfig is much like a
vimrc or Chief O'Brien's rank: a very
Nonetheless, it's one of those things where a few small adjustments to
the system-wide git configuration (a la
/etc/gitconfig) can make things
much, much easier — particularly in the case where there are multiple systems
to manage, and multiple people using them.
I'm pretty happy with those defaults, but a lot has changed since 2014.
The configuration paths available have also changed:
To do this, we can leverage the little-used system-wide git config file at
/etc/gitconfig. Remember that by default git looks at four files to
determine its configuration (in ascending order of priority):
~/.gitconfig(user aka global), and
.git/config(configuration for the current repository).
(Technically, #2 is
This allows us to set defaults in the system configuration file without
interfering with people who prefer different settings: their global config at
~/.gitconfig will win.
For our purposes, we're talking about settings in
they can certainly be used in other places as well.
This config sets a couple safer defaults for pushing, makes git merge/diff/rebase a little more DWIM, causes the committer, as well as the author, information to be displayed by default, as well as allowing for an easy way to override the system config on a per-system basis. (In case, say, you're using puppet or the like to distribute this configuration across multiple hosts.)
Note that we do not do some things that individuals may wish to do, as we're
aiming for "unobtrusive, reasonable universal defaults", e.g.
rebase.autosquash is not set to
true. (Though the author highly
recommends this setting.)
fzf is a fantastic utility, written by an author with a history of writing useful things. He's also a vim user, and in addition to his other vim plugins he has created an "enhancement" plugin called fzf.vim.
One of the neat things
fzf.vim does is make it easy to create new commands
for fuzzy searches. If you're like me, you probably have some absurd number of project
repositories you keep around and jump to, as necessary. Not everything is in
the same directory (e.g.
~/work/), naturally, and with a laptop, desktop,
and a couple other machines the less-frequently used repos may be where one
least expects them to be — or not present at all.
It's not hugely annoying, just a sort of mild pain to have to spend several
extra seconds doing a fuzzy search manually, rather than having
fzf do it.
But we do have
fzf, and it's not difficult at all to build out a new search,
so there's really no reason to keep on inflicting that pain.
Let's create a new command in my vimrc,
:Projects, that invokes
fzf to search through all the different work
directories I have.
What does this do?
Defines a new vim command,
No surprises here.
fzf#run() to run a
fzf#run() handle the actual execution and presentation of
fzf, as well
has dispatching the results back to the
fzf#wrap() is neat. It allows a command to take advantage of
option handling -- or not, by simply omitting it.
find to look for repositories
We know roughly where to look(
~/.vim/plugged) and how deep to
look. Just about everything I do is backed by git, so we can look for
repositories and return the parent of the found
.git back to
Note that the
find invocation deliberately omits a
-type d argument. I
do use git workdirs, meaning
.git may well be a file (a "gitlink").
Calls out to
rsrchboy#fzf#FindOrOpenTab() with the project selected
sink option tells
fzf#run() what to do with the results. In our
case we have provided
fzf#run() with a callback function, but you can also
use built-ins as sinks.
In general, I use one tab per project (repository) in vim. For me, this is a
nice balance of utility and sanity. It also allows me to do things like set
t:git_workdir to the git and workdir, respectively, of the
repository associated with the tab.
Our callback function first attempts to find an open tab with the workdir
requested; if found, it just switches to it and returns. (It should probably
admonish me to read the tab line before invoking
If not found. the callback function invokes
fzf#run() again. This time we
git ls-files to generate the source list for
fzf, allowing us to pick
a file to be opened by the given
Easier than writing this post, I'd say ;)
...um, kinda. I'm switching over from wordpress to Statocles, and porting my older posts over.
Still, who can resist "first post!" ;)
Google DNS is being hardcoded into a significant number of devices now. Which is nice, because it pretty much always works.
...except when you're trying to use Netflix and you have a tunnelbroker IPv6 tunnel. Ugh.
So, this is a brief followup to Stupid OpenWRT tricks. Or maybe "Getting Netflix to work when your ISP doesn't support IPv6 yet" is a better way to put it...