The problem autosaved solves

Developers use Git as part of their day to day toolset. Everyone knows that you are supposed to commit often so that you don't lose your work by mistake. Yet sometimes, developers take their time to commit because they don't want to push something raw or because they sometimes just forget to push something or because they just feel lazy on that day.
It's highly improbable that they may lose their work. They are aware of this fact and slightly fearful of this improbability. What happens after they do it many times? The improbable day that they most feared comes and they do something to delete the work they pulled in an all-nighter, irrecoverably.
While they may blame themselves for not pushing to Git often, the problem is too common among developers that at this point it must be the tools to blame that they don't do enough to accommodate these humans who are their normal careless selves.
I myself lost my progress on a blog I wrote after a lot of hard work. That is why I created autosaved, a tool that automatically takes care of saving my work so that I can undo to whatever. I never have to worry if I am constantly committing my code to Git as a measure to not lose it. Moreover, since I use Git for my main use, it shouldn't interfere with any of my usual developer flow. And autosaved checks that box too.
Hence, I made this tool autosaved, which really truly won't let you lose your work when using Git.

Challenges I ran into

• go-git: I was using a library called

  go-git

  I had used in the past but not too much. I knew some git terminology but this experience showed me how much I hadn't known. I struggled for one full night and the morning after to use that library to save changes without touching the user's main branch, or anything involved in their main developer flow. This meant, no use of staging index, the current branch, or anything else that may cause noticeable disturbance to the user. I fixed this at the end with a hack that quickly saved the changes and always reverted to the user's original state even in case of failures. This worked excellently for me.
• UI: The UI had to be pretty for it to be of any good use to anyone. I tried to keep it as utalitarian as I could and cut down on unnecessary features and showbells. There had to be an easy way for the user to revert to a past state as everyone may not be as familiar with Git, and it may be hard to remember combinations. This I solved with colors, simple alignment for visual recognition in the git listing, and a human readable notation of time that would say "this much time ago" instead of a robotic timestamp that's much harder to digest. I think that went quite well too.
• Concurrency issues and daemon communication: It was exciting thinking of concurrency issues with Go. I had to place a lockfile mechanism, handle syscall.SIGTERM and os.Interrupt signals to gracefully delete the lockfile and close any open channels. That was very very exciting.
• Time crunch: I felt quite lazy on the day of 8th Jan. I felt quite lazy, I had the idea but it was very vague and I was just restless about getting to complete it. Finally I found my rhythm and completed it to usability overnight.