git/strbuf.h, branch v2.6.3

strbuf: make stripspace() part of strbuf

2015-10-16T16:45:15Z

This function is also used in other builtins than stripspace, so it makes sense to have it in a more generic place. Since it operates on an strbuf and the function is declared in strbuf.h, move it to strbuf.c and add the corresponding prefix to its name, just like other API functions in the strbuf_* family. Also switch all current users of stripspace() to the new function name and keep a temporary wrapper inline function for any topic branches still using stripspace(). Reviewed-by: Matthieu Moy Signed-off-by: Tobias Klauser Signed-off-by: Junio C Hamano

Merge branch 'jk/date-mode-format'

2015-08-03T18:01:27Z

Teach "git log" and friends a new "--date=format:..." option to format timestamps using system's strftime(3). * jk/date-mode-format: strbuf: make strbuf_addftime more robust introduce "format" date-mode convert "enum date_mode" into a struct show-branch: use DATE_RELATIVE instead of magic number

Merge branch 'mh/strbuf-read-file-returns-ssize-t'

2015-07-13T21:00:27Z

Avoid possible ssize_t to int truncation. * mh/strbuf-read-file-returns-ssize-t: strbuf: strbuf_read_file() should return ssize_t

strbuf: strbuf_read_file() should return ssize_t

2015-07-04T01:25:02Z

It is currently declared to return int, which could overflow for large files. Signed-off-by: Michael Haggerty Signed-off-by: Junio C Hamano

introduce "format" date-mode

2015-06-29T18:39:10Z

This feeds the format directly to strftime. Besides being a little more flexible, the main advantage is that your system strftime may know more about your locale's preferred format (e.g., how to spell the days of the week). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

strbuf_addch: avoid calling strbuf_grow

2015-04-16T15:15:05Z

We mark strbuf_addch as inline, because we expect it may be called from a tight loop. However, the first thing it does is call the non-inline strbuf_grow(), which can handle arbitrary-sized growth. Since we know that we only need a single character, we can use the inline strbuf_avail() to quickly check whether we need to grow at all. Our check is redundant when we do call strbuf_grow(), but that's OK. The common case is that we avoid calling it at all, and we have made that case faster. On a silly pathological case: perl -le ' print "[core]"; print "key$_ = value$_" for (1..1000000) ' >input git config -f input core.key1 this dropped the time to run git-config from: real 0m0.159s user 0m0.152s sys 0m0.004s to: real 0m0.140s user 0m0.136s sys 0m0.004s for a savings of 12%. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

strbuf.h: group documentation for trim functions

2015-01-16T22:40:47Z

The relationship between these makes more sense if you read them as a group, which can help people who are looking for the right function. Let's give them a single comment. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

strbuf.h: drop boilerplate descriptions of strbuf_split_*

2015-01-16T22:40:47Z

The description of strbuf_split_buf says most of what needs to be said for all of the split variants that take strings, raw memory, etc. We have a boilerplate comment above each that points to the first. This boilerplate ends up making it harder to read, because it spaces out the functions, which could otherwise be read as a group. Let's drop the boilerplate completely, and mention the variants in the top comment. This is perhaps slightly worse for a hypothetical system which pulls the documentation for each function out of the comment immediately preceding it. But such a system does not yet exist, and anyway, the end result of extracting the boilerplate comments would not lead to a very easy-to-read result. We would do better in the long run to teach the extraction system about groups of related functions. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

strbuf.h: reorganize api function grouping headers

2015-01-16T22:40:47Z

The original API doc had something like: Functions --------- * Life cycle ... some life-cycle functions ... * Related to the contents of the buffer ... functions related to contents .... etc This grouping can be hard to read in the comment sources, given the "*" in the comment lines, and the amount of text between each section. Instead, let's make a flat list of groupings, and underline each as a section header. That makes them stand out, and eliminates the weird half-phrase of "Related to...". Like: Functions related to the contents of the buffer ----------------------------------------------- Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

strbuf.h: format asciidoc code blocks as 4-space indent

2015-01-16T22:40:47Z

This is much easier to read when the whole thing is stuffed inside a comment block. And there is precedent for this convention in markdown (and just in general ascii text). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano