JGit and CGit
Jonas Fonseca
created over the course of a few weeks. Unfortunately, I have had only
little time to spend on it after it got merged due to 99% of my usage
got covered.
Personally, I am not opposed to switching back to CGit or offering
both with JGit as a fall-back, if you think it will help create a
great git module faster and get more people involved (including you).
However, I think it would be wrong to completely abandon JGit, since
it offers some nice features, which will allow a "native" gitk-like
TopComponent that I think is an improvement over the current history
browser.
On Wed, Apr 29, 2009 at 14:05, Lincoln Stoll <lstoll...@lstoll.net> wrote:
> Is JGit still definitely the way forward? I've forked off the old cli
> branch, and made a few hacks to get status (including ignored) and
> committing working properly, and I'm probably going to do further work
> here. I'm dogfooding it myself, and much happier now ignored files
> aren't showing up in the list. It still needs plenty of other features
> added, but correct status and committing is 99% of my usage.
>
> It's not just the .gitignore thing, but JGit also doesn't seem to
> support submodules, instead throwing an exception - which is
> frustrating. I note that one of the reasons for choosing JGit was
> better cross platform, and tighter integration. Command line seems
> good enough for the mercurial module and the IntelliJ git module, plus
> git is getting much better on windows.
>
> Thoughts?
--
Jonas Fonseca
Lincoln Stoll
of both having an easy fallback, as well as the added GUI stuff.
For now, I think I might move forward to the latest source, and add a
CGitCommand class, which implements the status stuff using cgit. The
normal GitCommand class can check if CGit is available, and if so pass
the call back to CGitCommand. This would at least give us
basic .gitignore support on the repositories, until JGit gets this.
I'll also investigate how to at least stop the exceptions on
repositories that have submodules. This sound OK?
Whilst longer term it would be nicer to add the features to JGit
instead of dropping back to CGit, I'm fairly time constrained as well,
and using CGit if availble for certain things is a much quicker win.
Linc.
Jonas Fonseca
> For now, I think I might move forward to the latest source, and add a
> CGitCommand class, which implements the status stuff using cgit. The
> normal GitCommand class can check if CGit is available, and if so pass
> the call back to CGitCommand. This would at least give us
> basic .gitignore support on the repositories, until JGit gets this.
> I'll also investigate how to at least stop the exceptions on
> repositories that have submodules. This sound OK?
Yes, that would be great. I will try to finalize the last parts before
0.2 so it can be released this week. After this, I would like to give
focus on addressing some of the reported issues. Once accomplished, I
can take a look at you branch and we can start figuring out how to
merge your work.
--
Jonas Fonseca
iGEL
You're pushing for having a backend for the standard C implementation?
That's good news!
One of the reasons for me to switch from Eclipse to Netbeans was that
it uses the official C implementation of Subversion, which I was using
at that time. Maybe I do not know all the details, but I don't see any
advantage of having a pure Java implementation of a VCS, if that VCS
is widely used and open source. I'm sure, every platform which can run
netbeans has already a working git version. ;) With Subclipse and
Subversive, there where always some small differences to the C
implementation and there was always a delay, when Subversion got new
features. Having a good wrapper seems more gainful to me.
I thank both of you for your efforts to bring git to Netbeans. Also I
glad to see nbgit moving forward. :)
Regards, Johannes
Shawn O. Pearce
>
> One of the reasons for me to switch from Eclipse to Netbeans was that
> it uses the official C implementation of Subversion, which I was using
> at that time. Maybe I do not know all the details, but I don't see any
> advantage of having a pure Java implementation of a VCS, if that VCS
> is widely used and open source.
IIRC, nbgit used to use C Git as the backend, then moved to JGit
as JGit matured more.
I don't know all of the details with SVN, but IIRC the SVN folks
have been mucking around (quite badly) with the local client on
disk format and the network protocol, so much so that only the
official libsvn can keep up. Git over that same time period has
not seen changes. Or, where we have, they are very small, planned
well in advance for maximum compatability, and JGit implements the
changes before they become the defaults. Git has a much better
track record of keeping things stable than SVN has.
I don't know about the license for NetBeans, but EGit likes using
JGit because EGit is under the Eclipse Public License (EPL) and
the EPL is not compatible with the GPL. The Eclipse Foundation
cannot distribute EPL code which links to, or executes, GPL code,
as it creates a larger combined work which cannot be redistributed
due to the EPL and GPL fighting over which license the combined
work is covered by. JGit being under a new-style BSD removes that
issue entirely.
Also, EGit installs on any platform that has a Java 5 JRE. No need
for additional software installation. Just the other day someone
reported running JGit on VMS. C Git doesn't compile or run on that
platform, but it has a Java 5 JRE, so JGit works.
--
Shawn.
bkw
On May 2, 4:41 pm, Lincoln Stoll <lstoll+li...@lstoll.net> wrote:
> I'll also investigate how to at least stop the exceptions on
> repositories that have submodules. This sound OK?
still crashes...
regards,
bkw