git/strbuf.h, branch v2.6.2

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

strbuf.h: drop asciidoc list formatting from API docs

2015-01-16T22:40:46Z

Using a hanging indent is much more readable. This means we won't format as asciidoc anymore, but since we don't have a working system for extracting these comments anyway, it's probably more important to just make the source readable. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano