git/strbuf.h, branch v2.10.2

Merge branch 'rs/use-strbuf-addbuf' into maint

2016-08-08T21:21:42Z

Code cleanup. * rs/use-strbuf-addbuf: strbuf: avoid calling strbuf_grow() twice in strbuf_addbuf() use strbuf_addbuf() for appending a strbuf to another

strbuf: avoid calling strbuf_grow() twice in strbuf_addbuf()

2016-07-22T16:22:26Z

Implement strbuf_addbuf() as a normal function in order to avoid calling strbuf_grow() twice, with the second callinside strbud_add() being a no-op. This is slightly faster and also reduces the text size a bit. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

Merge branch 'pb/strbuf-read-file-doc' into maint

2016-07-06T20:06:45Z

Minor doc update. * pb/strbuf-read-file-doc: strbuf: describe the return value of strbuf_read_file

strbuf: describe the return value of strbuf_read_file

2016-06-14T17:57:21Z

Mentored-by: Lars Schneider Mentored-by: Christian Couder Signed-off-by: Pranit Bauva Signed-off-by: Junio C Hamano

Merge branch 'sb/submodule-parallel-update'

2016-04-06T18:39:01Z

A major part of "git submodule update" has been ported to C to take advantage of the recently added framework to run download tasks in parallel. * sb/submodule-parallel-update: clone: allow an explicit argument for parallel submodule clones submodule update: expose parallelism to the user submodule helper: remove double 'fatal: ' prefix git submodule update: have a dedicated helper for cloning run_processes_parallel: rename parameters for the callbacks run_processes_parallel: treat output of children as byte array submodule update: direct error message to stderr fetching submodules: respect `submodule.fetchJobs` config option submodule-config: drop check against NULL submodule-config: keep update strategy around

run_processes_parallel: treat output of children as byte array

2016-03-01T19:57:19Z

We do not want the output to be interrupted by a NUL byte, so we cannot use raw fputs. Introduce strbuf_write to avoid having long arguments in run-command.c. Reviewed-by: Jonathan Nieder Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

Merge branch 'jc/strbuf-getline'

2016-01-29T00:10:14Z

The preliminary clean-up for jc/peace-with-crlf topic. * jc/strbuf-getline: strbuf: give strbuf_getline() to the "most text friendly" variant checkout-index: there are only two possible line terminations update-index: there are only two possible line terminations check-ignore: there are only two possible line terminations check-attr: there are only two possible line terminations mktree: there are only two possible line terminations strbuf: introduce strbuf_getline_{lf,nul}() strbuf: make strbuf_getline_crlf() global strbuf: miniscule style fix

strbuf: give strbuf_getline() to the "most text friendly" variant

2016-01-15T18:23:57Z

Now there is no direct caller to strbuf_getline(), we can demote it to file-scope static that is private to strbuf.c and rename it to strbuf_getdelim(). Rename strbuf_getline_crlf(), which is designed to be the most "text friendly" variant, and allow it to take over this simplest name, strbuf_getline(), so we can add more uses of it without having to type _crlf over and over again in the coming steps. Signed-off-by: Junio C Hamano

strbuf: introduce strbuf_getline_{lf,nul}()

2016-01-15T18:12:51Z

The strbuf_getline() interface allows a byte other than LF or NUL as the line terminator, but this is only because I wrote these codepaths anticipating that there might be a value other than NUL and LF that could be useful when I introduced line_termination long time ago. No useful caller that uses other value has emerged. By now, it is clear that the interface is overly broad without a good reason. Many codepaths have hardcoded preference to read either LF terminated or NUL terminated records from their input, and then call strbuf_getline() with LF or NUL as the third parameter. This step introduces two thin wrappers around strbuf_getline(), namely, strbuf_getline_lf() and strbuf_getline_nul(), and mechanically rewrites these call sites to call either one of them. The changes contained in this patch are: * introduction of these two functions in strbuf.[ch] * mechanical conversion of all callers to strbuf_getline() with either '\n' or '\0' as the third parameter to instead call the respective thin wrapper. After this step, output from "git grep 'strbuf_getline('" would become a lot smaller. An interim goal of this series is to make this an empty set, so that we can have strbuf_getline_crlf() take over the shorter name strbuf_getline(). Signed-off-by: Junio C Hamano

strbuf: make strbuf_getline_crlf() global

2016-01-14T23:05:55Z

Often we read "text" files that are supplied by the end user (e.g. commit log message that was edited with $GIT_EDITOR upon 'git commit -e'), and in some environments lines in a text file are terminated with CRLF. Existing strbuf_getline() knows to read a single line and then strip the terminating byte from the result, but it is handy to have a version that is more tailored for a "text" input that takes both '\n' and '\r\n' as line terminator (aka in POSIX lingo) and returns the body of the line after stripping . Recently reimplemented "git am" uses such a function implemented privately; move it to strbuf.[ch] and make it available for others. Note that we do not blindly replace calls to strbuf_getline() that uses LF as the line terminator with calls to strbuf_getline_crlf() and this is very much deliberate. Some callers may want to treat an incoming line that ends with CR (and terminated with LF) to have a payload that includes the final CR, and such a blind replacement will result in misconversion when done without code audit. Signed-off-by: Junio C Hamano