GSoC 2014 Idea: Git Manager Tool

joel_moniz

Hi everyone!

My name is Joel Ruben Antony Moniz, and I'm a second year student pursuing my B.E. (Hons) Computer Science at BITS Pilani, Pilani campus in India.

I have been using Processing for almost a year now. I have also been contributing to the project form around 2months now, and have submitted 2 pull requests to Processing (adding an AutoSave feature and adding a Progress Bar when Saving As), and am eagerly awaiting the community's opinion as to how those features are, how they can be improved, whether they violate any of the Processing project's coding styles, etc.

I'd love to take my participation in Processing to the next level by participating in GSoC 2014. In particular, I checked out the list of potential tools and the GitHub Integration idea caught my fancy. I have been using Github for a few months now, and this is a tool that I could really relate to. I did a project using Processing last summer, where I built an entire game from scratch. I have created a GitHub repo for it. When making the project, I kept Saving As at each stage, and changing the project name. I eventually ended up with around 8 copies of the same project! On looking back, I realize how much simpler and neater a version control like Git would have been. Further, if I ever plan to take the project to this next level, and make it a full blown game (along with a few friends, say), GitHub would provide me with everything I'd ever need to manage this operation effortlessly. This is what inspired me to come up with an idea for the implementation of a GitHub management tool in Processing.

To implement this, I'm thinking of using the JGit and the egit.github libraries. As a proof-of-concept, I have implemented a very basic tool for Processing which initializes a sketch folder as a git repo (the proof-of-concept can be found on GitHub here). This is only a very basic prototype, however, simply to test if my installation and use of the various libraries was correct and if the tool so created builds successfully and is able to utilize the editor object passed to it (in this case, I have used the editor object to access the current absolute path of the folder the sketch is stored in). Could someone please tell me if this is the correct method to proceed (especially with regard to the libraries used)?

Further, not having much experience in working on a project of this magnitude (in terms of time, and number of people it would, hopefully, affect), can someone please tell me if this idea is large enough (and sufficiently useful) for a GSoC project, or if it is too small?

In case it is too small, and if it is acceptable, could I implement a 2D Sketch tool for Processing as well? The tool will be something very roughly along the lines of the G4P Tool, but instead providing numerous 2D drawing features (for example, to draw rectangle, ellipses, triangles, polygons, et. al. and implement properties like stroke color and weight, fill color, etc.).

Looking forward to the community's feedback!!! :)

Yours sincerely,
Joel

EDIT: As per Mr. Phil's feedback, I will be integrating other online repo services into the tool as well. Hence, I have renamed the tool from "GitHub Manager" to "Git Manager". A minor technicality, but still :).

calsign

I don't necessarily speak for the rest of the Processing community (or the Processing developers), but I think that a Git client for Processing would be awesome. In fact, I've had similar ideas kicking around in the back of my head for a while. It wouldn't be an entry-level tool, but for the advanced developer... and, perhaps, it could include some sugar-coating for easing new users into the Git workflow.

I have a particularly vested interest in this type of project because I am currently working on a version of the PDE for running on Android devices. Specifically, I intend to integrate a Git client into the phone-side editor so that users can sync their work between their device and their desktop computer (Git is a bit more tech-savvy than DropBox or the like). With this approach, it would be necessary for me to create a Git client for the PDE as well. If someone else decides to do this, then that makes my job a bit easier.

As for libraries, I would definitely go with JGit. I haven't gotten a chance to start using it yet, but this is the library that great tools such as EGit are built on. For the Android side, I have reason to believe that AIDE also uses JGit.

So... will it make a great GSOC project? I don't know, but I'd like to think so. Will I support this project? Yes.

PhiLho

"It wouldn't be an entry-level tool, but for the advanced developer"
I disagree here. I believe such integration of Git in the PDE would be more aimed at the beginner (or medium level user) which haven't tried Git or even that doesn't know what a VCS is.

Advanced users just know already how to use Git (or Mercurial or Bazaar or even SVN, etc.) and doesn't really need such integration, as they use their tool from the command line or with good managers (I use Git Extensions, the BitBucket tool isn't bad either).

I think that such tool should be a bit independent of a host. GitHub is great, but it isn't the only free online repository. It should be used off-line too, of course! (that's the whole point of DVCS, anyway).

Somehow, it can offer a very simple workflow, and perhaps allow something a bit more advanced. Something like offering to take a snapshot of the current state of the code (ie. add & commit), and to go back to a previous version. That's the very base usage, covering what Joel was doing, keeping copies of various versions around (I did that too, before jumping into the VCS bandwagon).
Then, you can offer to do branches, to allow experimenting some parallel solutions.
Etc.

The difficulty is to keep the usage simple and transparent, with proper visualization of history, etc.

Note also that one can wonder if each sketch should have its repository or if it should be made at the sketchbook level, or at some intermediate level. There was a discussion about this at the start of this forum. I would choose to see the sketchbook as a whole repository, managing lot of little repositories can be unwieldy, no?

joel_moniz

Hey there. Thank you very much for the replies :).

A few points that I'd like to add based on your replies

Mr. Calsign,

"As for libraries, I would definitely go with JGit."

I was thinking of using JGit for the offline part of the tool, and egit.github only for the online, "Github-related" part of the tool . Would this be ok?

---

Mr. Phil,

"I think that such tool should be a bit independent of a host."

How would I go about this? I had planned to implement Github integration, Github being fairly popular, as you mentioned, many other web services similar to it exist (such as BitBucket). I had planned to have all the offline features, such as taking a snapshot, branching, etc. available, along with pushing to Github, pulling from it, etc, i.e., a mix of offline Git features integrated with the online features Github provides. Should I scratch the Github aspect of this tool, add other online repo services as well (like BitBucket and Google Code), or start off with Github, and extend it from there? If I am to include other repo services in this tool as well (possibly the best choice from these options, and convenient for both new and experienced users), which other such online repo services should I include?

---

"Note also that one can wonder if each sketch should have its repository or if it should be made at the sketchbook level, or at some intermediate level."

What if the Tool could offer the user the best of both worlds, with an option to select which of these he/she would like to do?

---

Also, regarding the level of proficiency of the user with Git, maybe I could add an option for the user to choose from beginner or advanced, and vary the features provided and the interface based on these? As a rough example, for beginners, include a "Take snapshot" option which adds and commits all files to which changes have been made in one go, and one for advanced users, which offers users the ability to explicitly select which files they'd like to add and commit (as 2 separate options), to create branches, et al. Further, a tutorial module can also be included, especially for new users, where one is shown how Git works, and how this tool can be used by them to access Git's power (as well as to conveniently use online repos, depending on which ones are to be included).

Further, considering that now the tool focuses not only on GitHub, perhaps I should rename it to something like "Integrated Git Client"?

Once more, in clarification, this tool would make a good GSoC project, right? Especially as now a number of features have been added (user levels with different interfaces based on user proficiency, tutorials, selection of whether an individual sketch should have its own repo, or whether the repo should be at the sketchbook level, including Google Code, BitBucket and other online repositories as well into the Tool, and a smooth visualization of both history (as Mr. Phil suggested) as well as branches in existance, etc.)?

PhiLho

Basically, you have lot of good ideas. You understood what I meant: make the tool to work independently of any GitHub account (off-line), but allow to use it if the need arises. You don't necessarily need to support all other online repositories (that can be lot of work, perhaps), but having pluggable support would be awesome. I am OK (for what my opinion is worth!) with only an initial support of GitHub, of course. :-)

joel_moniz

Thank you Mr. Phil :)

I have now updated the tool (and pushed it to the repo link above).

I have included both the "snapshot" feature for less experienced users, and the "add" and "commit" options for more advanced users (though I have not yet allowed them to explicitly add which files they want).

I have also added a push feature, where the user enters his username, password and online repo address, and his/her commits are pushed to the online repo. I have tested it successfully with GitHub, but am yet to do so with BitBucket, Google Code, etc., though it should work.

However, bug or two still exist in these options provided (like for example, a file the user is pushing shouldn't be of a large size than 1Mb; ignores deleted files when adding).

The UI is at present very very bare, and I'll work on it soon. I was thinking of something along the lines of Processing's UI, especially the Editor Toolbar that Processing has at the top. Perhaps a few icons at the top with the various actions the user might want to do, and a drop down menu from which the user can select which mode he'd like to work in- basic or advanced. The main screen shall show a list of files (and folders) and their statuses (unstaged, staged, committed), and this view will change based on user's actions: it may show the diff with last commit if user selects the file and then chooses the appropriate option (a feature particularly inspired from Tortoise git, which I found amazingly convenient and handy), it may show the branches in existence, a visualization of the history of the file, etc. Would this provide a reasonable degree of intuitiveness to the tool, to make it simpler for new users to work with?

Thanks :)

joel_moniz

Hello everyone.

So I've been thinking about various possible GUIs, and finally came up with this one:

I created the mock-up with pencil, and have uploaded the .ep file here.

Its a very rough draft of the finished product that I had in mind, though, and I'll definitely be working on some better, much more appealing icons on the Git Operations toolbar, a few modifications to the pane which currently shows the statuses of the various files, better color combinations, and a better overall appearance of the tool.

The pane which represents the status of the file will also be used for various other purposes, such as showing visualizations of file history, branches in existence, or the diffs of a particular file with respect to the last commit, based on which option the user chooses.

Further, I have shown the Online Repo options menu open. Based on which of these options the user chooses, a context-specific menu will appear below the Git Options menu, that resembles it (with icons for the user to choose from, and the icon set displayed depending on which online repo the user has chosen).

I needed a little more help regarding a few choices to be made:

1) Should the Online Repo options menu be shown only to advanced users? 2) Are there any changes or improvements I can make to the UI to make it better?

Thanks again :)
Joel