JGit vs. Git

JGit vs. Git

[Vagmi Mudumbai]

Hi,

I am a git and a jgit noob. Be gentle. :-)

1) Is JGit a drop in replacement of Git? In sense, if I were to pack
in an SCM with my app, Can I pack jgit instead of C Git?

2) I noticed that there are no 'add' and 'commit' commands (at least
from the source) in the org.spearce.git.pgm project. I am looking at
the repo.or.cz/egit.git repo. I had a brief look at the
lib/GitIndex.java and lib/Repository.java. GitIndex has the add
methods to add files/entries to the index. I am still stumped on how
commits can be done with JGit. Any help is hugely appreciated.

I am working on Windows with msysGit behind a HTTP Proxy. (Life cant
get worse, I guess.) . I planned on using grit via JRuby but grit uses
fork which is not available on funny platforms like windows. And JRuby
guys do not have any plan on supporting fork even on platforms on
which for is supported. If JGit is a pure Java based implementation of
Git with more or less the same functionality, then my work becomes a
lot easier.

Regards,
Vagmi

Re: JGit vs. Git

[Robin Rosenberg]

tisdag 06 januari 2009 07:50:11 skrev Vagmi Mudumbai:
> Hi,
> 
> I am a git and a jgit noob. Be gentle. :-)
> 
> 1) Is JGit a drop in replacement of Git? In sense, if I were to pack
> in an SCM with my app, Can I pack jgit instead of C Git?
Short answer: No. JGit is a library for implementing access to a Git
repository. It does not have nearly all functionality and the command
line interface is mostly for testing the internals and so it only has
what's needed for that purpose or because we like to. The command
set will become more complete over time.
> 
> 2) I noticed that there are no 'add' and 'commit' commands (at least
> from the source) in the org.spearce.git.pgm project. I am looking at
> the repo.or.cz/egit.git repo. I had a brief look at the
> lib/GitIndex.java and lib/Repository.java. GitIndex has the add
> methods to add files/entries to the index. I am still stumped on how
> commits can be done with JGit. Any help is hugely appreciated.

With the Eclipse plugin. If you want to implement the add and commit
commands, please do. You won't need much code for it. The class that
does adding in Eclipse is called Track, btw. You can also take a look at
unit tests for how to do things and the other commands for how to
write commands. It's very easy actually. Then submit your patch.

What is most apparently missing from the internals is handling patches.
We have patch reading (but not application), now, plus candidate for
creating diffs (it works, but needs to be libified, byte[]-ified and we want
to make it faster).

> I am working on Windows with msysGit behind a HTTP Proxy. (Life cant
> get worse, I guess.) . I planned on using grit via JRuby but grit uses
> fork which is not available on funny platforms like windows. And JRuby
> guys do not have any plan on supporting fork even on platforms on
> which for is supported. If JGit is a pure Java based implementation of
fork isn't really supported on Windows. Cygwin goes to great lengths to
emulate it. Trying to do that within the context of an arbitrary JVM seems
like a daunting task. Consider submitting patches to make grit not use fork...
just kidding.., please help us improve JGit instead :)

> Git with more or less the same functionality, then my work becomes a
> lot easier.

The intention is to be able to do anything useful with JGit too.

-- robin

Re: JGit vs. Git

[Stephen Bannasch]

At 12:12 PM +0100 1/6/09, Robin Rosenberg wrote:
>tisdag 06 januari 2009 07:50:11 skrev Vagmi Mudumbai:
>  > I am working on Windows with msysGit behind a HTTP Proxy. (Life cant
>>  get worse, I guess.) . I planned on using grit via JRuby but grit uses
>>  fork which is not available on funny platforms like windows. And JRuby
>>  guys do not have any plan on supporting fork even on platforms on
>>  which for is supported. If JGit is a pure Java based implementation of
>fork isn't really supported on Windows. Cygwin goes to great lengths to
>emulate it. Trying to do that within the context of an arbitrary JVM seems
>like a daunting task. Consider submitting patches to make grit not use fork...
>just kidding.., please help us improve JGit instead :)

Or think about extending the Ruby gem grit to also use JGit.  Which 
would certainly improve grit and  probably help improve JGit also.

I've thought about this a bit -- but it hasn't gotten to the top of 
my list yet ...

There are some examples of Ruby Gems which use Java libraries when 
run in JRuby and native C libraries when used from MRI.

   hpricot:   http://github.com/why/hpricot/tree
   redcloth:  http://github.com/jgarber/redcloth/tree/master

Re: JGit vs. Git

[Shawn O. Pearce]

Vagmi Mudumbai <vagmi.mudumbai@gmail.com> wrote:
> 1) Is JGit a drop in replacement of Git? In sense, if I were to pack
> in an SCM with my app, Can I pack jgit instead of C Git?

As Robin said, its not a full drop-in replacement.  That said, its
getting there.  We're now only really missing patch application,
diff generation, merge support, and submodule support.  Most of
the JGit core can handle submodules by skipping over them during
object traversal, but the part that talks to the filesystem to do
a checkout doesn't recognize them.

JGit is mostly a library, not a command line replacement.  But it
does have commands like "jgit init", "jgit clone", "jgit fetch",
"jgit push", even some server side tools like "jgit daemon",
"jgit receive-pack" and "jgit upload-pack".

To be honest I don't think anyone actually uses the command line
pgm stuff to work with Git.  Anyone using JGit is actually running
it embedded in some type of application like an IDE plugin or a
server like Gerrit.
 
> 2) I noticed that there are no 'add' and 'commit' commands (at least
> from the source) in the org.spearce.git.pgm project. I am looking at
> the repo.or.cz/egit.git repo. I had a brief look at the
> lib/GitIndex.java and lib/Repository.java. GitIndex has the add
> methods to add files/entries to the index. I am still stumped on how
> commits can be done with JGit. Any help is hugely appreciated.

As Robin said, look at the unit tests.  Basically you want to use
the Commit class to populate out the data fields, then pass it off to
an ObjectWriter instance to store it into the tree.  Finally you'll
need to use a RefUpdate (obtained from Repository's updateRef method)
to store the new ObjectId of that Commit into a ref like HEAD.

Unfortunately we have two commit representations in JGit.  If you
are trying to read data from a Repository the RevCommit (obtained
from a RevWalk) is orders of magnitude faster than the Commit class.

> I am working on Windows with msysGit behind a HTTP Proxy. (Life cant
> get worse, I guess.) . I planned on using grit via JRuby but grit uses
> fork which is not available on funny platforms like windows. And JRuby
> guys do not have any plan on supporting fork even on platforms on
> which for is supported. If JGit is a pure Java based implementation of
> Git with more or less the same functionality, then my work becomes a
> lot easier.

I plan on writing patch apply sometime this quarter I think.  I have
most of what I need to rip a patch apart and inspect it prior to
application, now I just need to line it up onto the base object
and issue the output version.

Diff might also come in the next few months.  Dscho has a nice
prototype working, but there's still some work to be done on it.

-- 
Shawn.

Re: JGit vs. Git

[Johannes Schindelin]

Hi,

On Tue, 6 Jan 2009, Vagmi Mudumbai wrote:

> I am working on Windows with msysGit behind a HTTP Proxy. (Life cant
> get worse, I guess.) .

FWIW I think all should work well if you use a proxy, such as 
http://www.meadowy.org/~gotoh/projects/connect

Hth,
Dscho

Re: JGit vs. Git

[Vagmi Mudumbai]

Hi,

@Stephen
>> Or think about extending the Ruby gem grit to also use JGit.  Which would certainly improve grit and  probably help improve JGit also.
I just started working on that. It will be close to Grit let me see
how far I get with it. If you have an existing repo that you have
already worked on, please feel free to share it.

The JGit code both tests and the UI is quite readable.

Thanks a ton for all your help. :-)

Regards,
Vagmi

http://blog.vagmim.com
"Teaching children to use Windows is like teaching them to smoke
tobacco—in a world where only one company sells tobacco." - Richard
Stallman