On Tue, 21 May 2013 22:56:21 +, Shawn Pearce wrote:
...
This was with JGit? A stack trace and JGit version (so we can
correlate line numbers) would be a much more useful bug report than
nothing at all.
I now have a full test case (involving a generated repo just shy of 1GB)
that will
On Tue, May 21, 2013 at 3:18 PM, Chico Sokol chico.so...@gmail.com wrote:
Ok, we discovered that the commit object actually contains the tree
object's sha1, by reading its contents with python zlib library.
So the bug must be with our java code (we're building a java lib).
Is there any
I'm not criticizing JGit, guys. It simply doesn't fit into our needs.
We're not interested in mapping git commands in java and don't have
the same RAM limitations.
I know JGit team is doing a great job and we do not intend to build a
library with such completeness.
Are you guys contributors of
Your code is broken. IOUtils is probably corrupting what you get back.
After inflating the stream you should see the object type (commit),
space, its length in bytes as a base 10 string, and then a NUL ('\0').
Following that is the tree line, and parent(s) if any. I wonder if
IOUtils
Solved! It was exaclty the problem pointed by Shawn.
Here is the working code:
File dotGit = new File(objects/25/0f67ef017fcb97b5371a302526872cfcadad21);
InflaterInputStream inflaterInputStream = new InflaterInputStream(new
FileInputStream(dotGit));
Integer read = inflaterInputStream.read();
On Wed, May 22, 2013 at 7:25 AM, Chico Sokol chico.so...@gmail.com wrote:
Your code is broken. IOUtils is probably corrupting what you get back.
After inflating the stream you should see the object type (commit),
space, its length in bytes as a base 10 string, and then a NUL ('\0').
Following
On Wed, May 22, 2013 at 7:20 AM, Chico Sokol chico.so...@gmail.com wrote:
I'm not criticizing JGit, guys. It simply doesn't fit into our needs.
We're not interested in mapping git commands in java and don't have
the same RAM limitations.
I guess you aren't trying to process the WebKit or Linux
Hello,
I'm building a library to manipulate git repositories (interacting
directly with the filesystem).
Currently, we're trying to parse commit objects. After decompressing
the contents of a commit object file we got the following output:
commit 191
author Francisco Sokol chico.so...@gmail.com
On Tue, May 21, 2013 at 4:21 PM, Chico Sokol chico.so...@gmail.com wrote:
Hello,
I'm building a library to manipulate git repositories (interacting
directly with the filesystem).
Currently, we're trying to parse commit objects. After decompressing
the contents of a commit object file we got
On Tue, May 21, 2013 at 5:21 PM, Chico Sokol chico.so...@gmail.com wrote:
Hello,
I'm building a library to manipulate git repositories (interacting
directly with the filesystem).
Currently, we're trying to parse commit objects. After decompressing
the contents of a commit object file we got
Ok, we discovered that the commit object actually contains the tree
object's sha1, by reading its contents with python zlib library.
So the bug must be with our java code (we're building a java lib).
Is there any non-standard issue in git's zlib compression? We're
decompressing its contents with
Chico Sokol chico.so...@gmail.com writes:
Hello,
I'm building a library to manipulate git repositories (interacting
directly with the filesystem).
Currently, we're trying to parse commit objects. After decompressing
the contents of a commit object file we got the following output:
Who
Chico Sokol chico.so...@gmail.com writes:
Ok, we discovered that the commit object actually contains the tree
object's sha1, by reading its contents with python zlib library.
So the bug must be with our java code (we're building a java lib).
Why aren't you using jgit?
--
To unsubscribe from
It was git who created that object.
We're trying to build a improved java library focused in our needs
(jgit has a really confusing api focused in solving egit needs). But
we're about to get into their code to discover how to decompress git
objects.
--
Chico Sokol
On Tue, May 21, 2013 at 7:22
Chico Sokol wrote:
We're trying to build a improved java library focused in our needs
(jgit has a really confusing api focused in solving egit needs).
JGit is also open to contributions, including contributions that
add less confusing API calls. :) See
On Tue, 21 May 2013 19:18:35 +, Chico Sokol wrote:
Ok, we discovered that the commit object actually contains the tree
object's sha1, by reading its contents with python zlib library.
So the bug must be with our java code (we're building a java lib).
That's interesting. We ran in a
On Tue, May 21, 2013 at 3:33 PM, Chico Sokol chico.so...@gmail.com wrote:
It was git who created that object.
We're trying to build a improved java library focused in our needs
(jgit has a really confusing api focused in solving egit needs).
JGit code... is confusing because its fast. We
On Tue, May 21, 2013 at 9:51 PM, Andreas Krey a.k...@gmx.de wrote:
On Tue, 21 May 2013 19:18:35 +, Chico Sokol wrote:
Ok, we discovered that the commit object actually contains the tree
object's sha1, by reading its contents with python zlib library.
So the bug must be with our java code
18 matches
Mail list logo
