Thomas Ferris Nicolaisen's blog

At work, we maintain patches for some pretty large open source repositories that regularly release new versions, forcing us to update our patches to match. So far, we've been using basic Git operations to transplant our modifications from one major version of the upstream to the next. Every time we make such a transplant, we simply squash together the modifications we made in the previous version, and land it as one big commit into the next version. Those who are used to very stringent keeping of Git history may wrinkle their nose at this, but it is a pragmatic choice. Maintaining modifications on top of the rapidly changing upstream is a lot of work, and so far we haven't had the opportunity to figure out a more clever way to do it. Nor have we really suffered any consequences of not having an easy to read history of our modifications - it's a relatively small amount of patches, after all. With a recent boost in team size, we may have that opportunity. Also the need for be

Over the last year, I've been increasingly doing a lot of blogging the intranet at work. As a consequence of this, I think I've felt less urge for blogging out here. The same way an open source developer builds a public profile by having their product shared in the open, I think it makes sense for people who don't work on code to do the same in the form of blogging, vlogging, tweeting or writing posts on Twitter/Facebook. Unfortunately, the content I write on the intranet is very specific to that culture. So it wouldn't be right to copy it in here. What I can do is to iterate some of the topics just quickly in this post, and then think about what topics are worth writing more about here. Your feedback is appreciated! Write a comment below or tweet me if you want to direct my writing in a particular direction. What do I do anyway For context, the last years my role has evolved quite a bit. I have a tricky profile to pin down into a role: I've drifted from s