Skip to content

G
git2
Switch branch/tag
  1. 27 Oct, 2011 1 commit
    • windows: Add support for non-UTF codepages · 11d51ca6 
      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.
      Vicent Marti committed
  3. 24 Oct, 2011 2 commits
    • Merge pull request #464 from rtyley/development · c2fbe423 
      Tolerate zlib deflation with window size < 32Kb
      Vicent Martí committed
    • Tolerate zlib deflation with window size < 32Kb · c51065e3 
      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
      Roberto Tyley committed
  5. 22 Oct, 2011 1 commit
  7. 20 Oct, 2011 1 commit
  9. 18 Oct, 2011 1 commit
  11. 15 Oct, 2011 1 commit
    • mwindow: close LRU window properly · 5fa1bed0 
      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>
      Carlos Martín Nieto committed
  13. 14 Oct, 2011 5 commits
  15. 13 Oct, 2011 9 commits
  17. 12 Oct, 2011 19 commits