As I mentioned in my previous blog post, I was not so happy with gitin’s state. First of all, from a maintenance point of view, it was a dependency hell. Also, it had a really complex code that tries to do some library to behave that is not meant to. For instance, the promptui library which is developed by manifoldco was not intended to have a use case like this. So I had to fork it and make patches to it. Even if I do that, I still had issues that I need to deal with. So it was really frustrating to get basic functionality. By the way, the library is really nice, I used several functions from it but it didn’t fit into my problem. And it is also worth to mention that documentation of that project is awesome.
Also, the git package in gitin was not making me happy too. Because it was not following the separation of concerns discipline so it was messy. I really liked to use src-d/go-git while I was developing gitbatch but it had some performance issues on my use cases so I couldn’t use it. Instead, I stick on libgit2/git2go to deal with a repository. The performance of libgit2 is outstanding so I made the decision. But it was a little bit complicated at the beginning since the very nature of being a rookie on handling git repositories.
So I started to develop the clone of gitin from scratch. I named it sig, to be shorter. Honestly, I prefer to use it as sig but that’s not a big deal. I started with some experiments to replace promptui for rendering. I managed to do so, it was really a nice thing that I got rid of my most complex dependency. After that, I started to re-write the git package as a separate project to use it in gitbatch also. Since I like the interface of go-git project, I created my own API to libgit2 with go-git’s approach. Which is hosted here. With these two improvements now I have much more control on software’s behavior and also it is much faster since I removed a lot of overhead. Also, I decided to use git with two different approaches; If I am going to read something from the repository I use libgit2 on the other hand if the user going to create an action such as doing a commit or request to read diff of a file I use git itself. This approach is much better than the previous one since it really reduced the complexity and also improved usability.
Now the development branch of gitin is merged with the clone and it is ready for testing. It is not finished yet though. I want to improve the terminal interface and I still couldn’t find the best solution for printing the output to the terminal. The current code has some code duplications that needs to be reviewed and I want to support both colour output along with black and white output. This kind of changes won’t affect the behavior so not so important from a users point of view.
It is worth to mention that I am going to drop pre-filter abilities (say flags of the branch, log and status commands) of gitin which were:
branchCommand = pin.Command("branch", "Checkout, list, or delete branches.")
There will be only main commands such as branch, log and status. With this, it will be much straightforward to use. It clearly reduces code complexity. Also, I tried to reduce the real estate of the screen so I removed the controls line. You will be prompted with controls when you simply type
So here is the comparison of two different versions of gitin. I used
gitin status command for the demo. In the left you are looking to the new version, on the right there is the old one.
The help output will be like:
Also I stick on fuzzy search rather than giving the user the choice of the search algorithm. I think fuzzy search does fine and covers %99 percent of use cases. I used fuzzy instead of using my own fork. In order to give more information about the search results, I added underline to the matched characters in the string.
gitin branch command will be look something like this:
I plan to release v0.2.0 in a couple weeks so stay tuned.
I would like to hear your thoughts about this post. If you want to share with me, you can find me on Twitter.