git/compat, branch v2.7.0

Merge branch 'js/emu-write-epipe-on-windows'

2015-12-22T22:45:16Z

The write(2) emulation for Windows learned to set errno to EPIPE when necessary. * js/emu-write-epipe-on-windows: mingw: emulate write(2) that fails with a EPIPE

mingw: emulate write(2) that fails with a EPIPE

2015-12-21T16:59:04Z

On Windows, when writing to a pipe fails, errno is always EINVAL. However, Git expects it to be EPIPE. According to the documentation, there are two cases in which write() triggers EINVAL: the buffer is NULL, or the length is odd but the mode is 16-bit Unicode (the broken pipe is not mentioned as possible cause). Git never sets the file mode to anything but binary, therefore we know that errno should actually be EPIPE if it is EINVAL and the buffer is not NULL. See https://msdn.microsoft.com/en-us/library/1570wh78.aspx for more details. This works around t5571.11 failing with v2.6.4 on Windows. Signed-off-by: Johannes Schindelin Acked-by: Johannes Sixt Signed-off-by: Junio C Hamano

Merge branch 'ad/sha1-update-chunked' into maint

2015-12-08T22:05:03Z

Apple's common crypto implementation of SHA1_Update() does not take more than 4GB at a time, and we now have a compile-time workaround for it. * ad/sha1-update-chunked: sha1: allow limiting the size of the data passed to SHA1_Update() sha1: provide another level of indirection for the SHA-1 functions

Merge branch 'ad/sha1-update-chunked'

2015-12-04T19:19:10Z

Merge branch 'js/misc-fixes' into maint

2015-11-05T20:18:13Z

Various compilation fixes and squelching of warnings. * js/misc-fixes: Correct fscanf formatting string for I64u values Silence GCC's "cast of pointer to integer of a different size" warning Squelch warning about an integer overflow

sha1: allow limiting the size of the data passed to SHA1_Update()

2015-11-05T18:35:11Z

Using the previous commit's inredirection mechanism for SHA1, support a chunked implementation of SHA1_Update() that limits the amount of data in the chunk passed to SHA1_Update(). This is enabled by using the Makefile variable SHA1_MAX_BLOCK_SIZE to specify chunk size. When using Apple's CommonCrypto library this is set to 1GiB (the implementation cannot handle more 4GiB). Signed-off-by: Atousa Pahlevan Duprat Signed-off-by: Junio C Hamano

Merge branch 'js/misc-fixes'

2015-10-30T20:07:00Z

Silence GCC's "cast of pointer to integer of a different size" warning

2015-10-26T20:24:03Z

When calculating hashes from pointers, it actually makes sense to cut off the most significant bits. In that case, said warning does not make a whole lot of sense. So let's just work around it by casting the pointer first to intptr_t and then casting up/down to the final integral type. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

compat/mingw.c: remove printf format warning

2015-10-23T17:17:53Z

5096d490 (convert trivial sprintf / strcpy calls to xsnprintf) converted two sprintf calls. Now GCC warns that "format '%u' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int'". Instead of changing the format string, use a variable of type unsigned in place of the typedef-ed type DWORD, which hides that it is actually an unsigned long. There is no correctness issue with the old code because unsigned long and unsigned are always of the same size on Windows, even in 64-bit builds. Signed-off-by: Johannes Sixt Acked-by: Jeff King Signed-off-by: Junio C Hamano

prefer memcpy to strcpy

2015-10-05T18:08:05Z

When we already know the length of a string (e.g., because we just malloc'd to fit it), it's nicer to use memcpy than strcpy, as it makes it more obvious that we are not going to overflow the buffer (because the size we pass matches the size in the allocation). This also eliminates calls to strcpy, which make auditing the code base harder. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano