5:36 p.m.
I just installed the latest (0.6.xx.....) integration build of the Eclipse plugin, and
they've added a ton of stuff. Check out the user guide [1], which has screenshots and
instructions. You can now:
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/dna-dev
Thanks,
JPAV
_______________________________________________
dna-dev mailing list
dna-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/dna-dev