At this point, everyone has already heard that Microsoft is buying GitHub. Acquisitions of this scale take time, but most expect everything to be official by 2019. The general opinion online seems to be one of unease, and rightfully so. Even if we ignore Microsoft’s history of shady practices, there’s always an element of unease when somebody new takes over something you love. Sometimes it ends up being beneficial, the beginning of a new and better era. But sometimes…
Let’s not dwell on what might become of GitHub. While GitHub is the most popular web-based interface for Git, it’s not the only one. For example GitLab, a fully open source competitor to GitHub, is reporting record numbers of new repositories being created after word of the Microsoft buyout was confirmed. But even GitLab, while certainly worth checking out in these uncertain times, might be more than you strictly need.
Let’s be realistic. Most of the software projects hackers work on don’t need even half the features that GitHub/GitLab offer. Whether you’ve simply got a private project you want to maintain revisions of, or you’re working with a small group collaboratively in a hackerspace setting, you don’t need anything that isn’t already provided by the core Git software.
Let’s take a look at how quickly and easily you can setup a private Git server for you and your colleagues without having to worry about Microsoft (or anyone else) having their fingers around your code.
Continue reading “Keep it Close: A Private Git Server Crash Course”
FabDoc is an interesting concept that attempts to tackle a problem many of us didn’t realize we had. There are plenty of version control systems for software, but many projects also have a hardware element or assembly process. Those physical elements need to be documented, but that process does not easily fit the tools that make software development and collaboration easier. [Kevin Cheng] sums FabDoc up as “a system to capture time-lapse pictures as pre-commits.”
With FabDoc a camera automatically records the physical development process, allowing the developer to focus on work and review later. The images from the camera are treated as pre-commits. Upon review, the developer selects relevant key images (ignoring dead ends or false starts) and commits them. It’s a version control and commit system for the physical part of the development process. The goal is to remove the burden of stopping the work process in order to take pictures, automatically record the development process and attach it to a specific project, and allow easy management of which images to commit.
The current system uses a Raspberry Pi Zero with a camera mounted on safety glasses, and some support software. Some thought has certainly gone into making the system as easy to use and manage as possible; after setting up a repository, scanning a QR code takes care of telling the system what to do and where to put it. The goal is to make FabDoc fast and easy to use so that it can simply work unattended.
We saw a visual twist on version control some time ago with a visual diff for PCBs, which was a great idea to represent changes between PCB designs visually, diff-style. It’s always exciting to see someone take a shot at improving processes that are easy to take for granted.
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.
Continue reading “Stupid Git Tricks”
Git is one of those tools that is so simple to use, that you often don’t learn a lot of nuance to it. You wind up cloning a repository from the Internet and that’s about it. If you make changes, maybe you track them and if you are really polite you might create a pull request to give back to the project. But there’s a lot more you can do. For example, did you know that Git can track collaborative Word documents? Or manage your startup files across multiple Linux boxes?
Git belongs to a family of software products that do revision (or version) control. The idea is that you can develop software (for example) and keep track of each revision. Good systems have provisions for allowing multiple people to work on a project at one time. There is also usually some way to split a project into different parts. For example, you might split off to develop a version of the product for a different market or to try an experimental feature without breaking the normal development. In some cases, you’ll eventually bring that split back into the main line.
Although in the next installment, I’ll give you some odd uses for Git you might find useful, this post is mostly the story of how Git came to be. Open source development is known for flame wars and there’s at least a few in this tale. And in true hacker fashion, the hero of the story decides he doesn’t like the tools he’s using so… well, what would you do?
Continue reading “History of Git”
We love Git. We know everyone has their favorite version tracking tools. But even those that don’t care for Git should see the value of getting meaningful Diff data from tracking Eagle layout files.
Was that last sentence just gibberish to you? Let’s take a step back. A few years ago it was impossible to use version control with Eagle at all because the schematic and PCB layout software used to save its files as binaries. But then Cadsoft transitioned to saving Eagle files as XML. This opened the door for things like scripting to rename parts en masse and to track the files under version control. One problem with the latter has been that performing a Diff on two different versions of a file results in XML changes that are probably not human readable. [Patrick Franken] wrote this script to add at least a glimmer of meaning.
We’d love to see some kind of side-by-side highlighting on the schematic or board renderings themselves. But that’s quite a ways off if we ever actually see it. For now his script will take the Diff and print out the tables seen above denoting which types of changes were made from one version to the next. It’s a start, and we hope it inspires even more work in this area.
There’s a fine line between solving problems that don’t exist and solving problems that no one recognizes until a solution is found. The former shows up with housewares peddled on late-night infomercials, while the latter is summed up by [Henry Ford], “If I asked people what they wanted, they would have said faster horses.” [Dave]’s method of storing microcontroller code in the cloud definitely falls into the ‘useful’ category.
[Dave] first realized the problem when he was digging around the IDEO Toy Lab and came across an orphan project, a Barbie credit card swiper. [Dave] had no idea if the firmware for this project was saved on the server, or even if the current version was available. One solution to this problem could be burning a copy of the source onto the Flash or EEPROM on the board.
There’s a problem with this idea, though: storing the source in an Arduino’s memory takes space. Thinking laterally, [Dave] realized that editing source happens on a computer, computers are connected to the Internet, so why not keep the source “in the cloud?”
[Dave]’s solution is to host the source on GitHub, and tie every piece of code to a board’s unique USB serial number. This gives every Arduno a unique ID, allows for version control, and libraries of multiple files.
This very clever addition to the Arduino IDE is up on GitHub
, ready to be added to any Arduino installation. Why the Arduino IDE doesn’t already have this feature is beyond us, but that’s what you get when you want a faster horse.
As the Open Source Hardware movement gathers steam, it has become clear that the tools to work collaboratively on hardware are in the dark ages when compared with slick frameworks like Git used to work on software projects. We’ve read a fair amount about this lately, but the idea of visual difference generation for PCB layout is one of the better proposals we’ve seen.
Of course the big difference when it comes to version control is that software is text, but hardware is graphic and only represented by text for the computer to use. It’s easy to use the ‘diff’ command to show you what text is out and what text is in, but that doesn’t translate to a schematic. [Windell] is using command-line utilities to produce a schematic that colors changes differently for easy visual detection. This means exporting before and after schematics as PDF files or images, then using ImageMagick to process them. He also points out that there’s a package out there called DiffPDF that will let you compare differences in PDF files automatically.
Check out what he has to say in his article, and make sure you get to the bottom where he suggests ways you can help. We agree that it shouldn’t be hard to roll visual diff functionality into open source software packages used for hardware design, and to integrate that into version control systems. It’ll just take some time for the concept to proliferate.