Stupid Git Tricks

My apologies if you speak the Queen’s English since that title probably has a whole different meaning to you than I intended. In fact, I’m talking about Git, the version control system. Last time I talked about how the program came to be and offered you a few tutorials. If you are a dyed-in-the-wool software developer, you probably don’t need to be convinced to use Git. But even if you aren’t, there are a lot of things you can do with Git that don’t fit the usual mold.


Tracking Documents

Git is really good at tracking changes in documents. If you write plain text files, Markdown, or TeX files, you are in business. However, there is a trick you can use if you use Word, OpenOffice, or many other word processing programs. As a benefit, you’ll even be able to collaborate with others using different programs.

The trick, described in this post and this one, is to configure Git to use a program called Pandoc to convert your input files into Markdown. The Git program can store both, and you can explain to it that differences in the Markdown file correspond to the differences in the document file.

Pandoc is a tool worth knowing about anyway. It converts to and from a dizzying number of formats. If you want to give yourself a headache, you can expand the graphic from their site and try to trace all the lines.

We’ve seen this sort of thing work for collaborative textbooks and even used to track frequently changing documents like French legal codes going back to the time of Napoleon.

Working on a Web Site

You can easily extend the idea of tracking documents to tracking HTML pages for your website. You could just use it as you create and then upload your files like normal. You can also use specialized workflows. Even if you are the sole creator of the site, being able to rewind to what the site looked like last week or last month is often unexpectedly useful.

Managing your Bash Profile or /etc

If you use Linux, you have a lot of files that configure your environment. Things like your .bashrc, .emacs, and so on are hard to keep the same if you use multiple machines. Sure, you can rsync them, but if they ever get messed up, it can be hard to go back and figure out what happened. That’s why I wrote a system for managing this problem using Git. Once it is configured, your machines will automatically pick up any changes you push to the remote host (I keep mine on GitLab). The system is flexible enough to allow for custom configuration per machine and even keep random files in sync for you with just a little setup.

There’s a similar package called etckeeper for keeping track of your system-wide configuration in the /etc directory. You could argue that configuration files are essentially just code, but the intent isn’t coding but keeping version control and synchronization between machines. Also, in the case of etckeeper, there are modifications so Git will store some metadata that is important for that application.

Git as a Database or Bug Tracker

If you are using Git for development, it only makes sense you could use it for tracking bugs, too. In fact, you can use Git as a simple database. Don’t expect to run SQL queries — this just shows a name-value pair system (the proverbial NoSQL database).

Of course, you can store SQLite database (or anything else) in Git. If you do, you can play some tricks like the Pandoc trick for documents to help Git understand your databases better.

Twitter (Yes, Twitter)

Ever wanted a distributed Twitter implementation? Check out Madrox. We aren’t really sure why we want this, but we do.

Text-based Slideshows

Have you ever wanted to show a progression of text screens like a slideshow? Maybe not, but if you did, Git can do that, too. It needs a little help from vim, though.


Even if you never need any of these tricks, some of the methods used to coax Git into doing something unusual might spur you to think of something else. An obvious idea would be a difference program for Gerbers or some other printed circuit board file format. Being able to see what changed between a few revisions of a PC board would be really useful. Obviously, being able to track schematics would be useful, too. Spice models ought to be no problem at all.

Have any useful Git hacks? Leave a link in the comments.

25 thoughts on “Stupid Git Tricks

  1. >Ever wanted a distributed Twitter implementation?
    Yes I have, but why force Git to do that? GNU Social has been doing it for years, and there are lots of other compatible servers (Mastadon being a notable example). It used to be mostly full of cool, Hackaday-ish people, but now it’s getting more popular and full of dull youngsters. Oh well, that’s life I guess.

  2. You did say stupid….
    Do not not forget to block public access to the version´ed copies of any script/cgi database server credentials on live sites:

    Order deny,allow
    Deny from all

    Order allow,deny
    Deny from all

    Order deny,allow
    Deny from all

    Order allow,deny
    Deny from all

      1. it is common for .svn and .git paths to be dumped into the web servers path with no permission preservation on cached version backups if some fool is using it for site backups.

        The post made no sense, as HaD did not like the regex filter tags for apache configuration to stop default public access to private site files.

        Telling people to use Git for site backups, and not warning them of this common error is just negligent.

        1. it’s not neglegent to not warn people using git for site backups. negligence is putting credentials in the path and adding them to version control in the first place. Credentials should not be stored and /or managed with projects, and should be handled separately in a password manager.

    1. History of textual data files can be nicely kept in a revision control system, but its usefulness is diminished without application-specific diff programs, especially for graphical information, but also for marked-up text. Any package using human-readable data files should also have a feature which displays highlighted overlays for changes represented as textual diffs, or as two instances of the project.

    2. Pretty sure the Git integration is built in to UE but disabled by default these days.
      Most binary assets from Unreal actually have a textual representation that is based on the old T3D format, which can be used to create diffs easily. You can see it by simply copying and pasting Blueprint or Material graph nodes into a text editor, for example.
      Perforce is considered by some to do binary files better, but isn’t great for working with heavily distributed teams.

  3. “If you are a dyed-in-the-wool software developer, you probably don’t need to be convinced to use Git.”
    Yes I do. I’ve used most if not all the other main players over the last 20+ years and GIT is the one that causes more pain by far. Use a command line to submit my work, what is this, 1984????

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.