This ensures that entries from the working directory are retrieved according to the following rules:

 - The file "subdir" should appear before the file "subdir.txt"
 - The folder "subdir" should appear after the file "subdir.txt"

status: Add a file in the test repository to cover the correct sorting of entries when the working folder is being read

In this case, "subdir.txt" should be listed before the "subdir" directory.

Fixes #465

Ensure that all memory related functions (malloc, calloc, strdup, free,
etc) are using their respective `git__` wrappers.

Their actual values have no meaning, so pack them in an enum.

Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>

Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>

The only caller has been changed to treat a NULL tree as a special
case and use the existing git_tree_entry_byindex.

Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>

This function is already implemented (better) as git_index_get. Change
the only caller to use that function.

Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>

Fixed crash in config parser when empty value is encountered.

Example:

key1 = value1
key2 =

In this config the value will be a bad pointer which config object will attempt to free() causing a crash.

tests-clay: move t01-rawobj.c to clay

Our previous assumption that all paths in Windows are encoded in UTF-8
is rather weak, specially when considering that Git is
encoding-agnostic.

These set of functions allow the user to change the library's active
codepage globally, so it is possible to access paths and files on all
international versions of Windows.

Note that the default encoding here is UTF-8 because we assume that 99%
of all Git repositories will be in UTF-8.

Also, if you use non-ascii characters in paths, anywhere, please burn on
a fire.

Signed-off-by: schu <schu-github@schulog.org>

Tolerate zlib deflation with window size < 32Kb

libgit2 currently identifies loose objects as corrupt if they've been
deflated using a window size less than 32Kb, because the
is_zlib_compressed_data() function doesn't recognise the header
byte as a zlib header. This patch makes the method tolerant of
all valid window sizes (15-bit to 8-bit) - but doesn't sacrifice
it's accuracy in distingushing the standard loose-object format
from the experimental (now abandoned) format. It's based on a patch
which has been merged into C-Git master branch:

https://github.com/git/git/commit/7f684a2aff636f44a506

On memory constrained systems zlib may use a much smaller window
size - working on Agit, I found that Android uses a 4KB window;
giving a header byte of 0x48, not 0x78. Consequently all loose
objects generated by the Android platform appear 'corrupt' :(

It might appear that this patch changes isStandardFormat() to the
point where it could incorrectly identify the experimental format as
the standard one, but the two criteria (bitmask & checksum) can only
give a false result for an experimental object where both of the
following are true:

1) object size is exactly 8 bytes when uncompressed (bitmask)
2) [single-byte in-pack git type&size header] * 256
   + [1st byte of the following zlib header] % 31 = 0 (checksum)

As it happens, for all possible combinations of valid object type
(1-4) and window bits (0-7), the only time when the checksum will be
divisible by 31 is for 0x1838 - ie object type *1*, a Commit - which,
due the fields all Commit objects must contain, could never be as
small as 8 bytes in size.

Given this, the combination of the two criteria (bitmask & checksum)
always correctly determines the buffer format, and is more tolerant
than the previous version.

References:

Android uses a 4KB window for deflation:
http://android.git.kernel.org/?p=platform/libcore.git;a=blob;f=luni/src/main/native/java_util_zip_Deflater.cpp;h=c0b2feff196e63a7b85d97cf9ae5bb258

Code snippet searching for false positives with the zlib checksum:
https://gist.github.com/1118177

Change-Id: Ifd84cd2bd6b46f087c9984fb4cbd8309f483dec0

Otherwise, GCC optimizes variables away and gdb can't tell us what's
in them.

Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>

Double-pass binary search. Jeez.

Remove a wrong call to git_mwindow_close which caused a segfault if it
ever did run. In that same piece of code, if the LRU was from the
first wiindow in the list in a different file, we didn't update that
list, so the first element had been freed.

Fix these two issues.

Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>

tests: propagate errors from open_temp_repo() instead of exiting

This makes it slightly easier to debug test failures when one test
opens a repo, has a failure, and doesn't get a chance to close it for
the next test. Now, instead of getting no feedback, we at least see
test failure information.

Update Makefile.embed with http-parser dependency

Add git_tree_frompath()

tree: Add git_tree_frompath() which, given a relative path to a tree entry, retrieves the tree object containing this tree entry

Improvements to tag, commit, and signature parsing

odb_pack: don't do ambiguity checks for fully qualified SHA1 hashes

This makes libgit2 more closely match Git, which only checks for
ambiguous pack entries when given short hashes.

Note that the only time this is ever relevant is when a pack has the
same object more than once (it's happened in the wild, I promise).

When trying to find the end of an email, instead of starting at the
beginning of the signature, we start at the end of the name (after the
first '<').

This brings libgit2 more in line with Git's behavior when reading out
existing signatures.

However, note that Git does not allow names like these through the
usual porcelain; instead, it silently strips any '>' characters it
sees.

Instead of bailing out with an error, this sets tagger to NULL when
the field is missing from the object.

This makes it possible to inspect tags like this one:

http://git.kernel.org/?p=git/git.git;a=tag;h=f25a265a342aed6041ab0cc484224d9ca54b6f41

The v0.99 tag in the Git repo triggers this behavior:

http://git.kernel.org/?p=git/git.git;a=tag;h=d6602ec5194c87b0fc87103ca4d67251c76f233a

Ideally, we'd allow the tag to be instantiated even though the tagger
field is missing, but this at the very least prevents libgit2 from
crashing.

To test this bug, a new repository has been added based on the test
branch in testrepo.git. It contains a "e90810b" tag that looks like
this:

    object e90810b8df3e80c413d903f631643c716887138d
    type commit
    tag e90810b

    This is a very simple tag.

This ensures commit->message is always non-NULL, even if the commit
message is empty or consists of only a newline.

One such commit can be found in the wild in the jQuery repository:

https://github.com/jquery/jquery/commit/25b424134f9927a5bf0bab5cba836a0aa6c3cfc1

Put them all together so we know where to find them.

Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>