user/sven/git.git/http-push.c, branch v1.7.7.4

Merge branch 'nd/maint-autofix-tag-in-head' into maint

2011-10-21T17:49:26Z

* nd/maint-autofix-tag-in-head: Accept tags in HEAD or MERGE_HEAD merge: remove global variable head[] merge: use return value of resolve_ref() to determine if HEAD is invalid merge: keep stash[] a local variable Conflicts: builtin/merge.c

Accept tags in HEAD or MERGE_HEAD

2011-09-18T21:11:40Z

HEAD and MERGE_HEAD (among other branch tips) should never hold a tag. That can only be caused by broken tools and is cumbersome to fix by an end user with: $ git update-ref HEAD $(git rev-parse HEAD^{commit}) which may look like a magic to a new person. Be easy, warn users (so broken tools can be fixed if they bother to report) and move on. Be robust, if the given SHA-1 cannot be resolved to a commit object, die (therefore return value is always valid). Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

whitespace: have SP on both sides of an assignment "="

2011-08-25T21:47:07Z

I've deliberately excluded the borrowed code in compat/nedmalloc directory. Signed-off-by: Junio C Hamano

Merge branch 'jc/zlib-wrap' into maint

2011-08-16T18:23:26Z

* jc/zlib-wrap: zlib: allow feeding more than 4GB in one go zlib: zlib can only process 4GB at a time zlib: wrap deflateBound() too zlib: wrap deflate side of the API zlib: wrap inflateInit2 used to accept only for gzip format zlib: wrap remaining calls to direct inflate/inflateEnd zlib wrapper: refactor error message formatter

zlib: zlib can only process 4GB at a time

2011-06-10T18:52:15Z

The size of objects we read from the repository and data we try to put into the repository are represented in "unsigned long", so that on larger architectures we can handle objects that weigh more than 4GB. But the interface defined in zlib.h to communicate with inflate/deflate limits avail_in (how many bytes of input are we calling zlib with) and avail_out (how many bytes of output from zlib are we ready to accept) fields effectively to 4GB by defining their type to be uInt. In many places in our code, we allocate a large buffer (e.g. mmap'ing a large loose object file) and tell zlib its size by assigning the size to avail_in field of the stream, but that will truncate the high octets of the real size. The worst part of this story is that we often pass around z_stream (the state object used by zlib) to keep track of the number of used bytes in input/output buffer by inspecting these two fields, which practically limits our callchain to the same 4GB limit. Wrap z_stream in another structure git_zstream that can express avail_in and avail_out in unsigned long. For now, just die() when the caller gives a size that cannot be given to a single zlib call. In later patches in the series, we would make git_inflate() and git_deflate() internally loop to give callers an illusion that our "improved" version of zlib interface can operate on a buffer larger than 4GB in one go. Signed-off-by: Junio C Hamano

zlib: wrap deflateBound() too

2011-06-10T18:18:17Z

Signed-off-by: Junio C Hamano

zlib: wrap deflate side of the API

2011-06-10T18:10:29Z

Wrap deflateInit, deflate, and deflateEnd for everybody, and the sole use of deflateInit2 in remote-curl.c to tell the library to use gzip header and trailer in git_deflate_init_gzip(). There is only one caller that cares about the status from deflateEnd(). Introduce git_deflate_end_gently() to let that sole caller retrieve the status and act on it (i.e. die) for now, but we would probably want to make inflate_end/deflate_end die when they ran out of memory and get rid of the _gently() kind. Signed-off-by: Junio C Hamano

http-push: refactor curl_easy_setup madness

2011-05-04T20:30:28Z

We were doing (nearly) the same thing all over the place, in slightly different orders, different variable names, etc. Refactor most calls into two helper functions, one for GET and one for everything else, that do the heavy lifting leaving most callsites a lot cleaner in the process. Note that the setting of CURLOPT_PUT at the callsites of curl_setup_http() which previously didn't do it (eg. locking_available(), remote_ls()) is safe, since that option is deprecated in libcurl in place of, and has the same effect as, CURLOPT_UPLOAD. Signed-off-by: Dan McGee Signed-off-by: Tay Ray Chuan Signed-off-by: Junio C Hamano

http-push: use const for strings in signatures

2011-05-04T20:30:28Z

Signed-off-by: Dan McGee Signed-off-by: Tay Ray Chuan Signed-off-by: Junio C Hamano

standardize brace placement in struct definitions

2011-03-16T19:49:02Z

In a struct definitions, unlike functions, the prevailing style is for the opening brace to go on the same line as the struct name, like so: struct foo { int bar; char *baz; }; Indeed, grepping for 'struct [a-z_]* {$' yields about 5 times as many matches as 'struct [a-z_]*$'. Linus sayeth: Heretic people all over the world have claimed that this inconsistency is ... well ... inconsistent, but all right-thinking people know that (a) K&R are _right_ and (b) K&R are right. Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano