During the last couple of years, the market of git clients for macOS kept becoming richer. There are now dozen of git clients, ranging from free to rather expensive, from open sourced to proprietary, from very actively developed to completely abandoned and with great variety of UIs and feature sets, probably covering everyone's needs. Yet if you're reading this, you're witnessing the introduction of a newcomer to the party: GitFinder. One may wonder what was the motivation to make yet another git client in the already crowded market. I think the opening blog post about GitFinder is the perfect opportunity to offer an explanation.
Through my years working as a software developer, I've never worked on a project which included more than three people coding. Mostly was I the only person producing the code and documentation at the given time frame. Therefore, my git needs are fairly modest; simple diffs check, commit, branch and sometimes tag creation, merge (extremely rarely having any conflicts), push and fetch/pull. All these are easily and quickly done in the terminal and that's how I was doing it when I started using git. And though command line interface is far from being unknown hostile territory to me, I always thought of myself as of a visual person and I always preferred using a nice UI. Hence I started experimenting with various git clients. I liked some better than others, but my general opinion was they were offering much more than I needed but without enough options to hide or exclude parts I didn't need.
Around the same time, Apple has finally come up with official way and API to extend Finder functionality and offer custom badges for icons, as well as contextual and/or toolbar menu items (actually, adding contextual menu items was possible prior macOS 10.6, but it required tons of Carbon code, while icon badging was never officially supported). That was in macOS 10.10, also known as Yosemite. I immediately remembered seeing people years before using TortoiseGit/SVN on Windows and thought it would have been nice to have something similar on Mac. However, the API in 10.10 was crippled in many ways (especially when it came to menus), so I just filled a bunch of bug reports and stopped thinking about it. As it usually happens in the last 7-8 years, Apple didn't bother fixing those things in minor updates, so most issues haven't been fixed before 10.11 (El Capitan) came out, a full year later.
With the biggest API issues fixed, I decided to give the whole idea another try. Pretty quickly I had something that could show icon badges and add git commands I used the most to Finder menus. And even though I never used TortoiseGit/SVN (as a matter of fact, I haven't used Windows in almost 10 years now), I immediately liked the way I could manage git operations in Finder. Still, I though (and hoped) someone else will eventually make it, as I was busy doing other things. As that was not happening, I was slowly adding more features and very soon my Finder extension was able to serve all of my (still modest) git needs.
Around that time (mid-2016) I discovered git client for macOS, which offered Finder integration and I was happy to see someone has finally made it. I was utterly disappointed though. To put it in a most subtle way possible, I passionately disliked it. And at that very moment I started thinking if I should I be the one offering something better. I decided to wait for some more time, but as anything similar wasn't appearing on the marked, I finally decided to bite the bullet and go for it. "If I like it and find it useful, surely there are other people who might feel the same", so was I thinking. Since by that moment many hours had already been spent on the project, I decided to commercialise it and offer it as a paid product.
Making the application commercial meant it needed to (try to) cover the needs of wider audience than only people who want to execute a few git commands here and there. Consequently, GitFinder started growing, getting more features, being more configurable and sporting richer UI. The end result is the application, which can be used solely as Finder's extension, giving you quick access to files' git statuses via icon badging and most frequently used git command via Finder contextual and/or toolbar item menu. But, you can also kick its repository browser window and use it as a separate, fully functional git client. Repository browser offers all you could expect from such client; full list of branches, tags, remotes, submodules and other references, commits list, commit diffs, commits search and others. All just a click in a Finder window away.
One additional piece of Information I would like to throw here… Another compelling reason I wanted to make GitFinder was playing and getting familiar with libgit2 library and making a git client the way I believed it should've been made. Almost all git clients for macOS utilise core-git command line tool running in the background, supplying it with input and interpreting its output using standard input, output and error pipes. They are wrappers around that tool. Some definitely very nice and functional, but still wrappers. For whatever reason, I always hated that concept. I'm willing to accept it when no other option is available, but I see it quite wrong if there is a library with nice API that can do the job. I don't know why I feel this way, perhaps that came from reading the official Version Control with Subversion book back in the days, where its authors Ben Collins-Sussman, Brian W. Fitzpatrick and C. Michael Pilato, in Chapter 8. Embedding Subversion in the note titled "Binding Directly—A Word About Correctness" wrote (I'll paraphrase):
"Why should your GUI program bind directly with the library instead of acting as a wrapper around a command-line program? Besides simply being more efficient, it can be more correct as well. A command-line is a program that needs to effectively translate feedback and requested data bits from C types to some form of human-readable output. This type of translation can be lossy. That is, the program may not display all of the information harvested from the API or may combine bits of information for compact representation. If you wrap such a command-line program with yet another program, the second program has access only to already interpreted (and as we mentioned, likely incomplete) information, which it must again translate into its representation format. With each layer of wrapping, the integrity of the original data is potentially tainted more and more, much like the result of making a copy of a copy (of a copy...) of a favorite audio or video cassette."
Many people probably wouldn't agree, but I have very strong opinion about this and in total agreement with the above statement. GitFinder binds with the libgit2 library and this is the perfect opportunity to say big THANK YOU to all of its developers and maintainers. Without the library and its reasonable and supportive licensing model, GitFinder wouldn't exist. Future development of GitFinder will require some contributions to the library and I will gladly do my part to make it better and more useful.
GitFinder is in its very infancy. There are many things still to be implemented, many things to be improved and probably many hidden bugs waiting to show their ugly heads and eventually be fixed. As a matter of fact, if you already have something on your mind, go to GitFinder-Issues and create an issue or join the discussion on an already existing one. But there is also a strong will and commitment to make it even better in every way possible. The day of official launch is just the beginning of what I hope to be an exciting journey.