git/commit.h, branch v2.2.2

Merge branch 'da/styles'

2014-09-19T18:38:35Z

* da/styles: stylefix: asterisks stick to the variable, not the type

Merge branch 'jk/commit-author-parsing'

2014-09-19T18:38:33Z

Code clean-up. * jk/commit-author-parsing: determine_author_info(): copy getenv output determine_author_info(): reuse parsing functions date: use strbufs in date-formatting functions record_author_date(): use find_commit_header() record_author_date(): fix memory leak on malformed commit commit: provide a function to find a header in a buffer

Merge branch 'jk/name-decoration-alloc'

2014-09-11T17:33:36Z

The API to allocate the structure to keep track of commit decoration was cumbersome to use, inviting lazy code to overallocate memory. * jk/name-decoration-alloc: log-tree: use FLEX_ARRAY in name_decoration log-tree: make name_decoration hash static log-tree: make add_name_decoration a public function

stylefix: asterisks stick to the variable, not the type

2014-09-02T18:33:32Z

Signed-off-by: David Aguilar Signed-off-by: Junio C Hamano

commit: provide a function to find a header in a buffer

2014-08-27T17:25:28Z

Usually when we parse a commit, we read it line by line and handle each individual line (e.g., parse_commit and parse_commit_header). Sometimes, however, we only care about extracting a single header. Code in this situation is stuck doing an ad-hoc parse of the commit buffer. Let's provide a reusable function to locate a header within the commit. The code is modeled after pretty.c's get_header, which is used to extract the encoding. Since some callers may not have the "struct commit" to go along with the buffer, we drop that parameter. The only thing lost is a warning for truncated commits, but that's OK. This shouldn't happen in practice, and even if it does, there's no particular reason that this function needs to complain about it. It either finds the header it was asked for, or it doesn't (and in the latter case, the caller will typically complain). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

log-tree: use FLEX_ARRAY in name_decoration

2014-08-27T14:44:27Z

We are already using the flex-array technique; let's annotate it with our usual FLEX_ARRAY macro. Besides being more readable, this is slightly more efficient on compilers that understand flex-arrays. Note that we need to bump the allocation in add_name_decoration, which did not explicitly add one byte for the NUL terminator of the string we are putting into the flex-array (it did not need to before, because the struct itself was over-allocated by one byte). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

log-tree: make name_decoration hash static

2014-08-26T17:34:26Z

In the previous commit, we made add_name_decoration global so that adders would not have to access the hash directly. We now make the hash itself static so that callers _have_ to add through our function, making sure that all additions go through a single point. To do this, we have to add one more accessor function: a way to lookup entries in the hash. Since the only caller doesn't actually look at the returned value, but rather only asks whether there is a decoration or not, we could provide only a boolean "has_name_decoration". That would allow us to make "struct name_decoration" local to log-tree, as well. However, it's unlikely to cause any maintainability harm making the actual data public, and this interface is more flexible if we need to look at decorations from other parts of the code in the future. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

log-tree: make add_name_decoration a public function

2014-08-26T17:33:01Z

The log-tree code keeps a "struct decoration" hash to show text decorations for each commit during log traversals. It makes this available to other files by providing global access to the hash. This can result in other code adding entries that do not conform to what log-tree expects. For example, the bisect code adds its own "dist" decorations to be shown. Originally the bisect code was correct, but when the name_decoration code grew a new field in eb3005e (commit.h: add 'type' to struct name_decoration, 2010-06-19), the bisect code was not updated. As a result, the log-tree code can access uninitialized memory and even segfault. We can fix this by making name_decoration's adding function public. If all callers use it, then any changes to struct initialization only need to happen in one place (and because the members come in as parameters, the compiler can notice a caller who does not supply enough information). As a bonus, this also means that the decoration hashes created by the bisect code will use less memory (previously we over-allocated space for the distance integer, but now we format it into a temporary buffer and copy it to the final flex-array). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

pretty: make empty userformats truly empty

2014-07-30T19:30:08Z

If the user provides an empty format with "--format=", we end up putting in extra whitespace that the user cannot prevent. This comes from two places: 1. If the format is missing a terminating newline, we add one automatically. This makes sense for --format=%h, but not for a truly empty format. 2. We add an extra newline between the pretty-printed format and a diff or diffstat. If the format is empty, there's no point in doing so if there's nothing to separate. With this patch, one can get a diff with no other cruft out of "diff-tree --format= $commit". Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'cc/replace-graft'

2014-07-27T22:14:18Z

"git replace" learned a "--graft" option to rewrite parents of a commit. * cc/replace-graft: replace: add test for --graft with a mergetag replace: check mergetags when using --graft replace: add test for --graft with signed commit replace: remove signature when using --graft contrib: add convert-grafts-to-replace-refs.sh Documentation: replace: add --graft option replace: add test for --graft replace: add --graft option replace: cleanup redirection style in tests