Imran M Yousuf <imyousuf@xxxxxxxxx> wrote: > I would like to volunteer to work in JGit; > can someone let me know where I can pick some tasks to implement? One of the areas that I think is really weak in JGit and that we need to do a _good_ fetch/push implementation is the branch model. For example, if you look at Repository.getBranches() it returns to the caller a Collection<String>. But in Git a branch is a heck of a lot more data, and that data is relevant to the end user when we are talking about fetch and merge. There are many configuration options stored in .git/config for a branch, and these are (today) created by git-branch and git-checkout automatically as the user creates and deletes branches. JGit has none of this model. It thinks all that a branch is is a String. Sad. Another thing that bothers me is the packed refs cache. We toss away the peeled information (the "^" lines), but that data is very useful when you are talking about fetch as well as a few other types of operations, like plotting tag labels onto a history graph (such as how gitk does it). The Ref class was started as a means of wrapping up the various important bits of data about a ref (of which branches are a subclass and annotated tags with peeled data is another) but I suspect it didn't quite do everything so these string APIs got created. The above is a farily small task, one that any good OO programmer should be able to tackle, but it can be challenging if you are new to Git plumbing as you'll have to learn what are the important parts of a branch/ref/annotated tag. As a starting point look at the config file format in C Git and see what is possible in a "branch" and "remote" section; that data needs to be pretty readily available for any Ref, if such data exists. The backward mapping of Ref->Remote (which does not exist yet, unless Robin created it) is quite relevant for tracking branches. -- Shawn. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
