Edward Thomson

Advent Day 19: Working Copy

December 19, 2018  •  1:04 PM

This is day 19 of my Git Tips and Tricks Advent Calendar. If you want to see the whole list of tips as they're published, see the index.

I've highlighted a few Git GUI clients this month: Git Kraken, which supports macOS, Windows and Linux, and Tower, which supports both macOS and Windows.

But today I want to mention a surprising GUI client: Working Copy. It's surprising because it's not a GUI client for a "proper" computer, it's a GUI for … your phone.

Okay, I'm embellishing a bit: it's actually a GUI for any iOS device, so you can use it from your iPhone, but you might find the most utility in using it from your iPad. But even there, I must admit that I was skeptical. After all, I don't have a compiler on my iPad. And I don't even have my trusty vim. But, I was intrigued, since I do have a keyboard…

And, honestly, it's even a pretty good keyboard. So I decided to give Working Copy a chance and I must say that I'm impressed. It's not ideal for working on code, I admit. But it is good for making a quick change when you don't need to compile and debug, and when you trust your continuous integration pipeline to catch any problems. Or maybe to a README or some documentation.

And it's great for editing my blog. Since I use jekyll, my entire web site is in a Git repository. And since I've been on vacation this week, I've wanted to minimize what I'm carrying around. So I can work on this Git advent calendar while just carrying around my tiny iPad. In fact, I'm writing this in Working Copy's text editor now:

Working Copy

I don't even need to run jekyll locally - I can just commit and push. I have an Azure Pipeline deployment set up for my blog, with a staging server and production. So when I push my master branch, it deploys to staging, where I can review it and decide if I'm happy. (Once I am, I click to advance my deployment to production.)

So I'm convinced. Working Copy certainly won't be the only Git client that I use, since most of the time I'm doing development and the iPad just isn't a great platform for that (yet?). But, I'm increasingly reaching for it when I'm working on docs or my blog.

After all, I'm in favor of any Git client that lets me work easily from a poolside.

Advent Day 18: Conditional Includes

December 18, 2018  •  1:04 PM

This is day 18 of my Git Tips and Tricks Advent Calendar. If you want to see the whole list of tips as they're published, see the index.

If you're a professional programmer who also works on open source software, then you might want to keep your work identity a bit separate from your personal identity. For example, I always use my personal email address when I'm working on my personal projects and open source software. In contrast, I always use my work email address when I'm committing to my work repositories.

At least, I try to always do that.

One of the things that helps ensure that I keep this organized is Git's conditional includes.

Instead of configuring both my user.name and user.email in my $HOME/.gitconfig, I set only my name (since that's the same everywhere). This is basically the template for all my Git repository configuration; then I can actually include other configuration files on a per-repository basis.

I keep my repositories in one of three places:

  1. $HOME/Microsoft (Unix) or C:/Microsoft (Windows) for my work repositories.
  2. $HOME/libgit2 (Unix) or C:/libgit2 (Windows) for my libgit2 and related repositories, and…
  3. $HOME/Projects (Unix) or C:/Projects (Windows) for all the other things that I work on.

So I can actually set my user.email based on the location of the repository that I'm working in. My $HOME/.gitconfig actually looks like:

[user]
    name = Edward Thomson
[includeIf "gitdir:C:/Microsoft/"]
    path = .gitconfig.msft
[includeIf "gitdir:C:/LibGit2/"]
    path = .gitconfig.oss
[includeIf "gitdir:C:/Projects/"]
    path = .gitconfig.oss

(Note the trailing slashes on the paths, those are required. Further note that they are forward slashes; this is true even on Windows.)

Then I also have a $HOME/.gitconfig.msft that contains my Microsoft-specific settings:

[user]
    email = ethomson@microsoft.com

And a $HOME/.gitconfig.oss that configures my settings for every other, non-work repository:

[user]
    email = ethomson@edwardthomson.com

I could also have just set a default user.email in my .gitconfig, and allowed another configuration to override it, but I like this forcing function. If I ever put a Git repository somewhere else, say in /tmp, now I must configure my email address explicitly. This protects me if I clone a work repository or a personal repository into a temp directory.

Advent Day 17: Whitespace in GitHub Pull Requests

December 17, 2018  •  1:04 PM

This is day 17 of my Git Tips and Tricks Advent Calendar. If you want to see the whole list of tips as they're published, see the index.

I hope that I've encouraged you to get your .gitattributes set up correctly so that everybody on your team is committing with the same line ending configuration. But maybe you haven't had time to fix that yet, maybe you're on holiday, or, heck, maybe you don't even care… 🤯

Even if some people on your team are still committing files with CRLF line endings, while others are committing with LF; some tools like GitHub have you covered.

If you see a pull request that appears to change every line (but there are only a few actual content changes) then that's a dead giveaway that somebody's line ending configuration is wrong. Here I've actually made changes only to lines one and three, but the diff makes it look like the whole file is rewritten:

Diff with whitespace changes

That's because the whole file is rewritten. I had Windows style line endings (CRLF) in the repository, but this pull request has rewritten the file with Unix style line endings (LF).

Now, you might not want to take a pull request that rewrites the whole file with new line endings. But in this case, I don't mind. I'm transitioning from having no .gitattributes and living in the wild wild west when it comes to line ending configuration, and I'm moving into the nice orderly world of Unix line endings.

But, what I really want here is to see just what actually changed, and ignore the lines that only had whitespace changes. And GitHub has me covered.

In the Diff Settings options at the top of the pull request diff tab, I can select "Hide whitespace changes".

Hide whitespace changes

When I do, GitHub will only show me the actual, non-whitespace differences in my pull request:

Diff with no whitespace changes

And now I can focus on reviewing what actually changed in the file, instead of the line endings.

Advent Day 16: All Things Git

December 16, 2018  •  1:04 PM

This is day 16 of my Git Tips and Tricks Advent Calendar. If you want to see the whole list of tips as they're published, see the index.

I hope you'll allow me a moment of shameless self-promotion: one of the great luxuries of my job is that I've been able to meet so many great people who are working on development tools, on helping people use version control, and to be better software developers in general.

And since I have so many great conversations with people, I decided to start recording them, along with my buddy Martin. The result is our podcast: All Things Git.

All Things Git

Over the past twenty episodes, we've talked to some of the people that bring you the tools that I've talked about this month, including GitKraken and Tower. And we've had a number of other great episodes, like looking at the history of version control, examining a Git security vulnerability and explaining how merge and friends actually work.

We've got new episodes coming in early 2019; I hope that you find it useful!

Advent Day 15: Tower

December 15, 2018  •  1:04 PM

This is day 15 of my Git Tips and Tricks Advent Calendar. If you want to see the whole list of tips as they're published, see the index.

Earlier this month, I suggested GitKraken as a graphical Git client. But just like you might prefer spaces over tabs (gasp!) or dark themes over light ones (what!?!), different people have different preferences when it comes to their Git clients, and I'd encourage you to try a few to find the one that you like.

Another great one is Tower. Tower was - in my opinion - actually the first modern Git GUI client: it was the first client that really worked to have an excellent and platform-native experience instead of something rather lackluster, or worse, just a text box where you typed git commands.

Tower for macOS

Tower was originally a macOS application, but I was really excited when Tower added Windows support a few years ago.

Tower for Windows

Tower has all the bells and whistles that you'd expect in a package that feels very native, whether you're on macOS or Windows. If you're looking for a GUI client to add to your workflow, I'd encourage you to check it out, too.