This is neat, but I think it's better to use your work provided device(s)/laptop for work, and your personal devices for personal things.
Obviously check your contract, and IANAL but people should be cognizant of the fact that your employer _may_ be able to retain copyright on personal projects if you use a work device (then again some contracts may even try to claim that they retain copyright for work done in personal time on personal devices)
I will never again accept a job where I must use a work-provided machine. I spend 8+ hours a day at work. Being forced to spend that time in some crappy, bloated, locked-down OS is 100% a quality of life issue. If I can provision and manage the machine myself, fine. I'll even purchase the hardware. Prefer it that way.
> I will never again accept a job where I must use a work-provided machine. I spend 8+ hours a day at work. Being forced to spend that time in some crappy, bloated, locked-down OS is 100% a quality of life issue. If I can provision and manage the machine myself, fine. I'll even purchase the hardware. Prefer it that way.
From experience, I totally understand your frustration - and to anyone in this situation, I would suggest leaving to a company that provides modern hardware. That being said, I humbly ask that you try to put yourself in the shoes of those who are charged with ensuring these machines remain complaint (contractual obligations that must be met). Meeting these compliance obligations means continued, uninterrupted business, and that business pays our salary.
From a security/compliance perspective, I don't think it's unreasonable to do your work on a locked down machine if you are able to do your job, assuming that you have a modern machine that will plow through the overhead effortlessly. If you weren't provided with a modern machine though that can do this - get out of there as fast as you can.
Modern hardware isn't a panacea. My work m1 laptop went from the fastest machine I've ever used to painfully slow as soon as the antivirus garbage was ported to arm64 and I had to start running it again.
It's really unfortunate how limited the current m1 systems are on ram. My current usage exceeds the available specs by far in that regard - 16gb, are they joking? There's nothing "pro" about 16gb of ram, that's pedestrian. You are absolutely right though, that no matter how good the hardware is there will always be bad software that manages to slog it down. I'm sorry that you have to deal with that.
Same here. Microsoft Defender is a real productivity killer. Cached C++ compilation now takes nearly twice as much time if the cache is hot.
And git operations or she'll prompts take forever in large repos like LLVM.
> From a security/compliance perspective, I don't think it's unreasonable to do your work on a locked down machine if you are able to do your job
Not at all. But from a security perspective I think it's also not unreasonable to request that my data isn't exfiltrated to some shady anti-virus company and my personal details aren't stored in a rancid (active) directory service.
I don't think it's reasonable to be forced to choose OSX or Windows. Not reasonable at all.
And I just... don't care anymore. I know it's not y'all's fault. It's the fault of the biz world which refuses to cater to any but the lowest common denominator. They could go for a solution that works with minimalist Linux systems so their sec suite doesn't conflict with my desired userland, like say a kernel extension interfacing with a daemon that just does the basics. Offer instructions and say you're on your own if you wanna go this route. Instead I get Carbon Black rammed down my throat. Which is better than McAfee but still. And McAfee still won't uninstall cleanly, and guess whether I have root access.
The problem is these companies simply don't want to work with their most capable and talented engineers. And, well, I just don't care anymore. These companies can just bleed talent to the free software sector for the next decade or two.
Depends on the workplace. I have company provided laptop (32G RAM, Ryzen 7 PRO 2700U) which was empty (well, Windows) and I just nuked it and install archlinux. There is no software provided by the company and no external control on the machine. So I just work-provided machine, but with my config and I just saved bunch of money since I did not have to buy it.
Maybe I'm thinking of Active Directory? I know there's something my company's IT department does on each machine that requires inputting a master secret and performing a kind of handshake with a central service.
Having a machine that is actually usable is orthogonal to having one dedicated to a job. Computers are dirt cheap, so have a separate one and it’s easy to keep your work products separated.
As an added bonus, it gives you one more place to run bloated^Wmandatory Electron apps.
Building a decent computer (only desktop, without a good monitor or peripherals) equals to spending at least three months' salary for me, probably more. JFYI, not every part of the world lives like Silicon Valley.
I'd rather keep my .gitconfig hacks and a single machine.
> Computers are dirt cheap, so have a separate one and it’s easy to keep your work products separated.
Not everyone has the same "dirt cheap" requirements for hardware for work; I work in games where a medium-range GPU is a requirement, and compiling large projects requires a much higer spec CPU (e.g. everyone on our team has at least a 3970x, which is ~$2000, and comes with a motherboard of $800). There's also space considerations - having two desktop machines works if you live in the US where houses are enormous; meanwhile I live in a 500sqft apartment with a 55 inch wide desk in my second bedroom - putting a second tower, plus extra power plus a KVM plus extra networking is a no-go.
> Having a machine that is actually usable is orthogonal to having one dedicated to a job.
Depends on the job. Work machines are often unusable because of measures mandated by employers to protect IP. Especially with big employers, you can't just get a random physical or virtual machine and do work-related things on it, not without angering the IT or cybersecurity department.
You probably exclude a large portion of possible workplaces if you argue that you need to keep their IP like a repo clone on a device they don't control. I doubt that will change any time soon.
The kind of company you want to work for in that cases is one that just lets you buy whatever machine you want, with a budget that exceeds whatever you'd buy for your private one.
I came to a new company and their laptop budget wasn't enough for a Macbook, which is the OS I'm used to. I mean I get that I may be coming across as a prima donna, but the provided hardware just wasn't good enough - and I'm not hardcore enough to spend my days working in vim over SSH to their development VMs, which also aren't fast enough.
Anyway, I could work with my old macbook, but it's giving the ghost, the screen is fooked and getting that fixed is too expensive.
MacBooks are weak-ass machines. It seems most developers are forced (or at least strongly-pressured) into using them by employers these days, but they're horrible for serious development. The performance is just bad, and they either sound like a jet taking off with fans in overdrive all day, or they throttle down to avoid overheating. Most developers I know work on apps deployed in a Linux environment, and have to jump through hoops to get a usable Linux-like environment locally. Docker can help a bit, but it causes even more performance problems on machines that are already being pushed to their limit.
I've been working on MacBooks for work for the better part of a decade, in large part to keep my work and personal machines separate, but I was much better off when I just did work on my personal Linux machine. I also didn't have to deal with switching monitor inputs and KVMs and the clutter of a laptop taking up precious desk space.
I used my own machine while the work-provided laptop sat next to me the whole time until I was forced to use the provided laptop. On one hand, my life-work balance improved, on the other hand I loath the stupidly slow machine that seems limited in every aspect compared to my own.
Oof. That's a compelling point that I hadn't considered. I recently removed all of my personal stuff from my work laptop, minus my dotfiles clone. I might just fork that onto my work GitHub account now.
Author here (but not the poster) and I generally agree with that sentiment.
Personally, I do inquire about open source copyright clauses when applying for a job.
I don't do any development on my work laptop but I do push updates to my dotfiles and the notes section of my site from time to time which is mainly what I use it for.
As far as I understand, it is (was?) a big issue in California but I don't believe it was ever a thing here in New Zealand nor do I think it would hold up legally as I understand it.
> This is neat, but I think it's better to use your work provided device(s)/laptop for work, and your personal devices for personal things.
This is important when you are a salaried employee.
BUT: There's often very good reasons to do paid work on your personal equipment. If you're a contractor, if you juggle contracts, if you're a founder or an early employee...
Even keeping things separate, it can be nice to pull in your dotfiles, so if you consistently organize your computers in the same way, like with work stuff in ~/work or whatever, you can keep a checked in global git config that “just works” when you spin up a work box.
Personally I'm with you on keeping your personal/work device separated, but many people I know surprisingly have only a work laptop. If you're a free-lancer, you also might not have two separate devices. I work fo a consulting company, some of our contracts don't provide laptops but do require al our activity to happen on an e-mail address provided by them. As a result my time committing is split between using my company's email and some other company's.
This is useful anyway. On both my work and personal machines, I have two directories: `~/projects/{work,personal}`. On my work laptop, I keep my dotfiles in `~/projects/personal/dotfiles`, and everything work-related (including my work dotfiles repo) goes in the other directory. It means I can keep the same set of configuration on my work and personal devices without a tonne of faffing around.
My solution: I don't have a global username and email set up. I have user.useConfigOnly set to true, this causes a hard failure if i try to commit without my identity configured. And when i configure my identity, its on a per-repo basis only.
For my work, I connect to the office PC via Citrix. Benefits:
- My office PC is much more powerful than my laptop and I don't need to deal with its maintenance
- I can switch between work and office with couple of clicks
- No chances of accidental overlap as I don't see one while using the other (I run full screen); provides mental separation too
- I don't need to put Windows on my personal machine (I run Linux)
- No work stuff getting into personal machine or vice versa so I don't need to do workarounds such as the .gitconfig setup mentioned in the article
The only problem I have observed is that Citrix on Linux seems to have issues exposing the external webcam as an available device when I join a meeting from within the Citrix session (for which we use Citrix (!) WebEx no less!). Cheese on Linux can handle the webcam perfectly fine. When I absolutely must enable Video, I just connect to the meeting directly from my laptop (which is a rare requirement in my case). But this problem could be a show-stopper for those who use video regularly and connect from Linux (my colleagues who use Windows say it works fine for them).
I use a similar setup, except the meetings that I take on the local machine because the sound quality is much better and I avoid problems with the webcam.
The main issue I've faced while connecting from local machine is when I want to share my office PC's screen. All sorts of issues with resolution (complicated further due to dual monitor), only being able to either share or see the participants but not both and so on. Unfortunate that Citrix don't bother to improve the experience with Linux clients but not entirely surprising either.
Can someone elaborate on why this would be preferred over not using a global ~/.gitconfig? You can just use .git/config on a per-repo basis. Which is very convenient if you have multiple identities, and it prevents accidental commits using the wrong identity, because git refuses commits unless a user.email is configured.
If you're routinely working on many repositories and cloning new ones, it's more convenient to know that if you clone it into this directory, it will be configured for work. I have used a similar setup for a while now, and it's perfect for me.
I'm pretty sure that it's a 10-20 minute job to write a Git subcommand wrapper that checks out a work vs personal project, and then symlinks the correct config file for the repo, if someone chose to go this route.
Sure, but that's more like a solution for implementing something like in OP for if it didn't exist in git itself, not the 'why not just use per-repo config' that I responded to.
My thoughts as well. You can set some core commands to be different in your per-project git config which I find more flexible for SSH identities than using a the .ssh/host file.
Generally I prefer to keep both separated, either with two devices or two different OS users. I certainly wouldn't want to keep both on the same profile/device (especially since I have to deal with two profiles for the browser, password manager etc... anyway).
But when I need to make a quick exception to this (private project on my work device or work project on my private device), I'm just using the `.git/config` of the repository. It's far easier and reliable.
My solution to the author's problem is to use `direnv` with `.envrc` files. From those I set several ENV variables based on where in my file structure I'm currently located. Two of those top level variables are `GIT_AUTHOR_EMAIL` and `GIT_COMMITTER_EMAIL` which take priority over the global .gitconfig file values. That allows me to easily use a different identity based on what workspace I'm using.
I set this up differently: my user gitconfig has my personal email. In my work monorepo, I have a local gitconfig where I set/override the email and GPG settings.
This allows you to do it from one .gitconfig so that it automagically changes when you're in a work repo as opposed to a personal one.
My source lives in a directory called ~/src, bunch of different repos. My work source repos live in ~/src/company so this way, I point the global git config there when in a repo under that directory.
This is cool. In this specific case, you can also (1) not set the email in .gitconfig, and (2) set an environment variable `EMAIL`. Git will pick it right up.
Hmm, that is just about email. There can be other configs which we want to be different for work and personal. And having config in one file - like .work.gitconfig or .home.gitconfig looks better to me since I can find all the config at one place and do not need to look around all the places.
However, that is a personal choice, I understand :-)
Totally, it’s a great solution. Using the env var is nice for the case where you only need to vary the email. Especially nice if you have multiple orgs to commit under, but the rest of your config is just how you like it for all projects.
I was using that approach for a while, but the problem is if you're in the folder defined in the includeIf - and you clone new repository from there - it will use your root config, not the additional config.
includeIf path matching works only if the folder is already under git.
A solution is to make a dummy repo in the repo where includeIf points to - but that is annoying a little, as sometimes it confuses IDEs or makes shell (ZSH + addons) slower - as it tries to seek for changes.
The best solution I've found is to unconditionally include an additional config in the main config. But the additional config is coming from a dynamic location that I mount in my shell when I work. Basically during the working hour I mount my entire partition which is encrypted under ~/work. And I have my config under ~/work/.gitconfig. I have also there my additional shell config - so during working hours I have everything set up.
The cons is that I need to mount/unmount that partition every day.
As a freelancer, I use this technique to handle using my various client email addresses automatically based on directory structure. My old method involved unsetting my user info and an alias to set it on a per-repository basis, but this technique (which I only learned about a few months ago!) is clearly superior.
I still don't fully get the zero-trust thing. Surely having the service as secured as possible AND behind VPN is safer no? Multi-layer defense is a thing, no?
I personally think it is rather inelegant to reinvent portions of a programming language inside your configuration file format. "IncludeIf" seems to be like that. On top of that, if any modern language would combine "include" and "if" into one statement, then it would be frowned upon.
This is funny to me, because git config is one of the few bastions of sane configuration. The language is not turing complete, there's no real schema, it's not quite TOML, the tooling to read/write values is sublime. Your custom tools can just start using it however you want. Config is all local, nothing is inherited or executed from remote sources.
It's just key=value. Whether value is a URL, a number, a shell command -- totally up for interpretation.
Sure, not having a schema has it's downsides but by god, I love git config.
> This is funny to me, because git config is one of the few bastions of sane configuration.
Just give it a few years, and we'll have statements like "IncludeIfFileExistsAndSatfisfiesConditionXandY" and you'll be begging for a Turing complete language ;)
Also, what happens if your configuration file contains a typo, say "eemail" instead of "email"? My guess is that Git will simply ignore it, whereas in a programming language, you would call "set_email(...)" and you would get an error if the function didn't exist. Now that's what I call sanity.
I was hoping for a way to eg. set diff settings based on installed programs, but seems to have reached a compromise in that including a file which doesn't exist doesn't cause any visible errors, so I can just use a systemd-esque system where I include all the files and create them (as symlinks) when appropriate.
I have a shell script I use to set my defaults for gitconfig on personal projects, and have my user level gitconfig set up for work, but this is so much cooler. I already keep my personal junk in ~/Projects/donatj so that makes this easy!
Funny to see a blogpost. This is part from our onboarding. We ask github handle and ask people to use work email to commit to our repo. Hence the conditional so you can keep using your personal email for your own work or opensource.
Learned about this recently. Very useful for setting up commits to use different emails and commit signing to use different GPG keys depending on the context
That may work for some, but some of us work in lots of repos and having to configure it for every repo is cumbersome.
I have `~/Code/<me>` for personal, and `~/Code/<company>` for work stuff, I can do this trick and all ~/Code/<company>` repos use my work identity whether I have 1 repo in it or 1000. (Currently have 23).
If you want to trigger some specific behavior per directory, have a look at `chpwd` for zsh, it's a function you can redefine that gets called every time you enter a new directory. You could for example have a chpwd function that checks if you're under ~/work, if there's a .git directory, and then adjust the remotes as you wish.
Obviously check your contract, and IANAL but people should be cognizant of the fact that your employer _may_ be able to retain copyright on personal projects if you use a work device (then again some contracts may even try to claim that they retain copyright for work done in personal time on personal devices)