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 non-standard issue in git's zlib compression? We're
> decompressing its contents with java default zlib api, so it should
> work normally, here's our code, that's printing that wrong output:
> import java.io.File;
> import java.io.FileInputStream;
> import java.util.zip.InflaterInputStream;
> import org.apache.commons.io.IOUtils;
> File obj = new File(".git/objects/25/0f67ef017fcb97b5371a302526872cfcadad21");
> InflaterInputStream inflaterInputStream = new InflaterInputStream(new
>>> 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> 1369140112 -0300
>>> committer Francisco Sokol <chico.so...@gmail.com> 1369140112 -0300
>>> first commit
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 discarded the remainder of the line after the NUL and did not
consider the tree line.
And you wonder why JGit code is confusing. We can't rely on "standard
Java APIs" to do the right thing, because commonly used libraries have
made assumptions that disagree with the way Git works.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html