GSOC 2014/Student Application Lukky513/Git shell prompt daemon

An overview of your proposal

'Git shell prompt daemon' project is an attempt to improve complicated and git-reliant Fedora package management workflow. The situation sprouted an idea of a specialized git tool, being able to quickly report on repository status, fetch remote branches in background, etc. Project would consist of two parts: daemon doing the processing, and a fast client. Application core should be able to work with more than just git by using a plugin mechanism.

Developers working with git often need to check repository status - things like count of files changed, untracked, merge conflicts, etc. Moreover, it's important to keep repository up to date (in git that means fetching the remote, to make sure the local copy of remote branches is up to date, then maybe merging it). Package managers have to work with version control even more; it'd be important to provide them the statistics they might need "for free", without having to type additional commands and reading through their output - such actions tend to break the workflow and thought process, what results in time wasted.

The best place for such information is the command prompt, used like virtualenv does (it adds current project name to the prompt); such prompt should be dynamic, preferably representing state of the path we're currently in, for example in form:

[repository](branch)[stats] cwd$

The part of the project that would be responsible for the prompt would be the client, just passing information from the daemon.

The need you believe it fulfills

In project as big as The Fedora Projects, using repositories that count as much as 200,000 branches total at the moment those words are written, proposed application would help to maintain workflow. Such kind of dynamic prompt is easily achievable through simple script, using git as a backend, but they'd be terribly slow and killing the terminal responsiveness - effectively, no better than a simple alias.

The idea would be to provide package managers with a tool they could just install and not to worry about it's performance, and provide them with information that could save time, possibly without getting in their way.

Any relevant experience you have

I'm using git daily; as I always seek improvement in this area, I've got quite advanced in it's use. I have professional experience in C. I know the GNU/Linux environment very well; I know how to do anything I might need to improve the workflow, so I might try do it for others. I wrote quite a few programs in Python - mostly for personal use (and few bigger projects as assignments). I have broad view and some experience in other areas; such kind of insight makes it possible for me to write the high quality code.

How you intend to implement your proposal

The best way would be to include the necessary statistics in the line in bash. That might be achieved using the PROMPT_COMMAND variable. The original idea mentioned named pipes as a way to communicate with daemon; however, it'd either enable us to do one-way communication (only sending some request to daemon) or a two-way with synchronization problems. Instead of them, either Unix sockets or regular TCP/IP sockets would be used (TCP/IP sockets would have the obvious advantage of being able to respond to possible requests coming from the network by just binding to external address, if such a need ever happens).

Daemon part would be implemented in Python - performance od daemon's side isn't critical, as long as it has the data prepared, and Python code is relatively easy to write and maintain. Client program would be written in C or C++, mainly to reduce the overhead of Python at the startup. Client would just have to pass the information from the daemon.

Daemon should be able to do some actions like fetching remote branches, in order to reduce further hindrance upon workflow. This feature should be easy to disable, if user decides for any reason it isn't needed, because eg. it slows down the network in the moments unwanted.

The solution should be able to do some kind of caching. As the client can track the current working directory, it could be based on some kind of prefetching. Some bigger cache with status ready could also be made and refreshed upon fetch or some manual changes in repository directories.

Project wouldn't be completely git-reliant - git support would be implemented as a plugin, and daemon core should support such architecture. Other versioning software could also be supported. If it's possible, the core functionality should be just a framework for making quick, dynamic and cached prompt information plugins, not necessarily restricted to VCS.

Prompt data should be easily configurable, so the end user of project would be able to change it to whatever suits. Simple printf-like formatting string should be sufficient.

A rough timeline for your progress

• 21th April - start coding as soon as possible
• 30th April - proof-of-concept app working, showing simple prompt; starting work on plugin architecture
• 15th May - core architecture done; starting to work on git plugin
• 10th June - git support done; starting to work on cache; try to collect feedback from community
• 23th June - early version ready
• 1st July - caching done; freeze the work on features, prepare the main branch for package deployment (in order to check what's required); continue coding while possibly maintaining ready-to-ship state
• 20th July - features done; work on what remains - optimization, bug fixing, testing and documentation; collect feedback about possible improvements
• 5th August - stop working on improvements - clean up and get ready for shipping
• 18th August - everything done

Any other details you feel we should consider

I'm currently employed as a half-time worker. My working time is flexible though, and shouldn't give me any trouble (I don't need to do anything job-related outside my working hours). I'm going to study until June 25th, but most of my courses are projects, which have to be completed much sooner than that.

Have you communicated with a potential mentor? If so, who?

Yes. I have contacted Mikołaj Izdebski.