select a project, folder, package, or file and get the history (which includes a visual history), see all the information about any of the commits, and even do a diff between different commits or between a commit and my local workspace.
commit within Eclipse (this was a bit wonky on 0.4.0, but is nice and clean now). In fact, you can even click a checkbox and your commit will ammend a previous commit [3]
create branches (this dialogs is a bit sparse compared with the images on the site, probably because I'm using Git locally with a remote SVN repository, and all my branches are off of the 'master' branch, which is important for the Git-SVN integration)
see what changes you've made (what's been staged already); see [4]
quick-diff support to show in your editor which lines are changed in your local workspace (relative to the base commit); see [5]

Some of the dialogs don't show quite as much using my local Git as they do in some of the screenshots. I suspect this is entirely because I'm using Git locally with a remote SVN repository, and all my branches are based off of the 'master' branch, which is important for the Git-SVN integration.

Here are some limitations I see:

can't create a patch. This shouldn't be an issue, because you need to do this from the command line, as Eclipse won't create a single top-level patch per our Reference Guide. But we actually won't need patches, because if all feature/issue work is done on their own branches, the branches themselves have the necessary history and changes (as long as the branch is pushed to a common Git or accessible by those that need it).
I haven't found a way to merge branches
there's no Team Synchronization view. I think this isn't a natural way to think about pulling changes with Git anyway, since with Git things stay on their branches and you end up comparing or diffing branches (which is possible). I think this is a case of "there's a better way to do this with Git".

Overall, I find it extremely useful.

Best regards,

Randall

[1] http://wiki.eclipse.org/EGit/User_Guide

[2] http://www.eclipse.org/egit/

[3] http://wiki.eclipse.org/EGit/User_Guide/Commit#Ammending_Commits

[4] http://wiki.eclipse.org/EGit/User_Guide/State#Comparing_Content

[5] http://wiki.eclipse.org/EGit/User_Guide/State#Quickdiff

On Dec 8, 2009, at 4:43 PM, John Verhaeg wrote:

So what kind of Eclipse tooling if available for git, if any? I think the main thing I care about using Eclipse for over the command line regarding the repository is the comparison editors. Is there such an animal for git?

On Dec 8, 2009, at 4:23 PM, Randall Hauch wrote:

On Dec 8, 2009, at 3:37 PM, Daniel Florian wrote:

I've gotten by without using local branches so far and don't think I will all of sudden start using them just because we are made to use Git. So if that is the main reason to switch I'm not buying it.

To date, we've been very much on a "feature-boxed" release mode, where our releases are determined primarily by the completion of major features. Each of our releases has focused on one or several of the JCR 1.0 features, so the times between releases has varied wildly. This has (sort of) worked to date, but need to move to a "time-boxed" release schedule that is more inline with JBoss Community best practices and more conducive to open-source projects. And because 0.7 and 1.0 will have all of the critical JCR features (except versioning, which is optional and also coming soon), we will be moving to "time-boxed" releases with 1.1.

"Time-boxed" releases mean that our releases will be on a fairly regular schedule, and will include all of the features/fixes made up to that point. This means that if a feature is not ready, it will not be included in the release. And rather than remove incomplete features, we will instead be developing all features (and potentially all issues) on separate branches, and merging those changes onto the mainline release branch (and other branches) as deemed appropriate.

Working with multiple branches in Git is trivial and light-weight. I can easily merge multiple branches onto my branch (e.g., pull in some fixes that people have committed on other issue branches), and yet merging my branch onto the mainline branch is again very easy even whether or not the branches I pulled in were already merged. Git does all the bookkeeping for me.

Now, frankly, SVN merging scares the crap out of me because it's a PITA and very error-prone. JBoss.org is currently running version 1.4.2, which does not have support for "easier" merging, and we'd have to rely upon svnmerge.py[1] or something similar. Plus, even with the "easier" merging abilities of SVN 1.5, it still is difficult to merge a set of changes onto multiple branches (which may be required). Dan, you worked with SVN branches when working on the Eclipse plug-in - can you imagine doing that for every issue and feature? And what worries me even more is that we'd relax our dev policies and practices because of difficulties and limitations of a tool like SVN, when there are other far-superior tools readily available.

So please bear this in mind.

Best regards,

Randall

[1] http://www.orcaware.com/svn/wiki/Svnmerge.py
_______________________________________________
dna-dev mailing list
dna-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/dna-dev

Thanks,

JPAV

_______________________________________________
dna-dev mailing list
dna-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/dna-dev