In my dayjob we have these big (tens of gigabytes each) git repositories that houses the company’s flagship product. Mostly they contain C++ source files and some XML files for generating other source files. Also there are some Java sources and various scripting-language files. In any case the majority of the population are text source files. We keep binaries such as image and sound files in their own (separate) git repositories, which are also large.
Because of their size, building these projects also requires immense system resources. We have a number of custom-made scripts that are part of a distributed build system to compile and link these source files on the server and make use of the computing power of other servers in the data center.
We keep these git repositories on the repo/build Linux servers. Locally cloning the repositories to our workstations aren’t much workable since it needs a case-sensitive file system and the files need to be on the server to be compiled. Not to mention that we couldn’t frequently commit source files due to how code reviews are being done – but that’s another story fit for an entire post in itself.
Editing the source files are done by rsync-ing our working set back and forth between our workstations and the repo/build servers. We also have a custom IDE (based on Eclipse) that handles this rsync-ing. Some are contempt to use vim and edit the source files directly on the server itself.
My biggest pet peeve of this setup is with our source control system – which is git. Simple tasks that are easily done using a GUI application like SourceTree or Git Tower becomes a chore because we couldn’t access file repository locally. Activities like committing parts of a file, determining a file’s changes through different revisions, and resolving merge conflicts is a huge PITA when the command-line is the only way you can do it.What makes things worse is that just about every Git GUI applications need the entire repository to be accessible locally and not much usable if you can’t clone the entire repo to your computer.
Our custom Eclipse-based IDE does help with git somewhat, but not much. It can only add edited files to git’s staging area on the server but not much else. There is no support for rebasing, squashing commits, pulling changes from other branches, and that kind of intermediate-level source control tasks. Those can only be done via the terminal using the git executable located on the server.
I’ve been toying with the idea of a GUI “shell” app that connects to the server via ssh and runs the git command line program remotely on it. Thus the repository can remain on the server and the app’s purpose is to save you from remembering many of git’s arcane commands and give you a nice-looking view of your repository.
This shell application would fit nicely as an iPad app, mostly to be used “on-the-go”. There are four reasons why:
- A tablet is the better form-factor for computing while standing – in the subway and other public transports – and you don’t have access a desk to put your laptop on.
- An iPad still have much longer battery life than a Mac – about 10 hours vs 7 hours for a MacBook Pro (and the particular MBP models that can last for 7 hour are much heavier than an iPad).
- An iPad doesn’t have a user-accessible file-system and thus there is not much sense to “checkout” an entire repository into the iPad. Cloning an entire git repository would only make sense an all-in iPad-based IDE.
- You won’t want to type all those git commands via terminal apps like iSSH when all you want to is a few quick fixes while on the road. Moreover when you’re zipping at 80 kph in a cross-country train with a spotty 3G connection – waiting for a few seconds for each keystroke as you type is a real bummer.
Why not a desktop app? If this is made into a desktop app, it would compete directly with other git apps already present on the desktop – many of them free. Since this venture isn’t funded by a large company like Atlassian (for which SourceTree is), I need to make up for the time I’ll be spending to develop and support it. (Better yet if I can retire on it and move back to Indonesia – of course, that’s my wishful thinking).
What This Means To You
If you share a similar pain point as I do, speak up! Let me know if this is a problem worth solving and I’ll certainly solve it. Yeah, it’ll be a paid app, but it’s not going to be expensive (promise!). How much? I’m thinking around the areas of $40 or so. That’s still cheaper than Git Tower and probably I’ll start at a much lower price in early revisions and steadily approach that target price as I fix bugs and add features to the app.
Let me know what you think in the comments below. Remember: your feedback will be the more reason that this problem is worth solving and will motivate me more to make this app. No feedback, no app!
Do you enjoy this post? Enter your e-mail address below to receive articles like this one in your mailbox.