-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Git module #60
Comments
I have searched for a while, and I'm in pretty doubt between gitblit and jgit. Both are fairly active, and they cover a lot of git features (much more than we plan to use). The only problem that I saw in gitbit is that it does not use maven. However, if we only want to browse commits, I heavily recommend the use of gitective. It is built on top of jgit, and the code seems to be much more elegant. |
responsible for the local Git repository analysis within Groundhog. Starting with non-parameterized commit extraction and extraction of commits from a given user. Nothing finished just yet. Code in main package only present for current debugging and testing purposes, once the commit message extraction is done it will be moved to the groundhog-case-study [2] project. [1]: https://github.com/kevinsawicki/gitective [2]: github.com/gustavopinto/groundhog-case-study Related to #55 and #60
Gustavo, right now, I believe we just want to work with commits. I've searched the Internet for more info and I saw that JGit can be finely used with Gitective and so I'd choose JGit over gitblit. I also believe we won't have any maintainability problems with JGit. I've no doubt about using Gitective, the library is really good and the code is elegant, like you said it was. I've started working on this, trying to extract commits using both JGit and Gitective but I'm having trouble listing the commits of a project. This is probably a silly thing and I'm just not getting it because I must've been forgetting something. Please, @gustavopinto, have a look at the commit referenced by the link above and tell me if you find something :) The branch containing the temporary works of this issue is |
hey @rodrigoalvesvieira, the code is working now :-) the code is elegant, but the documentation is not so much.. |
Hey @gustavopinto! Awesome! Yeah, the docs are definitely insufficient :/ BTW, have you figured out how can we get individual commit data like commit date, commit message and such? |
Hmm.. I believe that when we have the commit on hand, we can use jgit to get more information about it. For example, we can use the RevCommit class. Some of its methods are: getCommitTime, getAuthorIdent, getShortMessage. But, later I'll check the jgit documentation, and then I'll report my findings here. |
ok, then :) -- rodrigo On Tue, Sep 10, 2013 at 4:06 PM, Gustavo [email protected] wrote:
|
I ask for insights from @fernandocastor, @gustavopinto and @pork9 about what are the top 5 most important features that Groundhog should cover for local git data extraction. Commits? Tags? What? |
Commits FTW! On Wed, Oct 9, 2013 at 7:15 PM, Rodrigo Alves [email protected]:
|
work can be merged and be used to solve some questions. Related to #60. * ft-new-git-module: Adding some documentation Refactoring method for counting commits that include a given file extension filtering commits that have altered java code. r #60 searching commits with gitective Adding Gitective [1] as a dependency and creating the class that will be responsible for the local Git repository analysis within Groundhog.
I think tags would be great too. So: |
Groundhog currently relies on github api to get information about commits. But, instead, we should perform local git analysis, probably using JGit or similar tool, which will increase our response time, and will be more scalable as well.
The text was updated successfully, but these errors were encountered: