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 re
On Wed, May 22, 2013 at 7:20 AM, Chico Sokol 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 kernel
repositorie
On Wed, May 22, 2013 at 7:25 AM, Chico Sokol 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 that is the
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();
wh
> 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 di
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 JG
On Tue, May 21, 2013 at 3:18 PM, 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).
>
> Is there any non-standard issue in
On Tue, May 21, 2013 at 9:51 PM, Andreas Krey 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 (we'r
On Tue, May 21, 2013 at 3:33 PM, Chico Sokol 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 spent a lot of time
tr
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 si
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
http://wiki.eclipse.org/JGit/User_Gui
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 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 this list: send th
Chico Sokol 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 wrote this commit
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
On Tue, May 21, 2013 at 5:21 PM, Chico Sokol 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 the following
On Tue, May 21, 2013 at 4:21 PM, Chico Sokol 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 the following
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 1369140112 -0300
comm
18 matches
Mail list logo
