git/strbuf.h, branch v2.14.2

Merge branch 'ab/strbuf-addftime-tzname-boolify'

2017-07-07T01:14:47Z

strbuf_addftime() is further getting tweaked. * ab/strbuf-addftime-tzname-boolify: strbuf: change an always NULL/"" strbuf_addftime() param to bool strbuf.h comment: discuss strbuf_addftime() arguments in order

strbuf: change an always NULL/"" strbuf_addftime() param to bool

2017-07-01T17:47:05Z

strbuf_addftime() allows callers to pass a time zone name for expanding %Z. The only current caller either passes the empty string or NULL, in which case %Z is handed over verbatim to strftime(3). Replace that string parameter with a flag controlling whether to remove %Z from the format specification. This simplifies the code. Commit-message-by: René Scharfe Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'rs/pretty-add-again'

2017-06-24T21:28:38Z

The pretty-format specifiers like '%h', '%t', etc. had an optimization that no longer works correctly. In preparation/hope of getting it correctly implemented, first discard the optimization that is broken. * rs/pretty-add-again: pretty: recalculate duplicate short hashes

strbuf.h comment: discuss strbuf_addftime() arguments in order

2017-06-24T18:15:59Z

Change the comment documenting the strbuf_addftime() function to discuss the parameters in the order in which they appear, which makes this easier to read than discussing them out of order. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

strbuf: let strbuf_addftime handle %z and %Z itself

2017-06-15T21:34:37Z

There is no portable way to pass timezone information to strftime. Add parameters for timezone offset and name to strbuf_addftime and let it handle the timezone-related format specifiers %z and %Z internally. Callers can opt out for %Z by passing NULL as timezone name. %z is always handled internally -- this helps on Windows, where strftime would expand it to a timezone name (same as %Z), in violation of POSIX. Modifiers are not handled, e.g. %Ez is still passed to strftime. Use an empty string as timezone name in show_date (the only current caller) for now because we only have the timezone offset in non-local mode. POSIX allows %Z to resolve to an empty string in case of missing information. Helped-by: Ulrich Mueller Helped-by: Jeff King Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

pretty: recalculate duplicate short hashes

2017-06-15T18:40:53Z

b9c6232138 (--format=pretty: avoid calculating expensive expansions twice) optimized adding short hashes multiple times by using the fact that the output strbuf was only ever simply appended to and copying the added string from the previous run. That prerequisite is no longer given; we now have modfiers like %< and %+ that can cause the cache to lose track of the correct offsets. Remove it. Reported-by: Michael Giuffrida Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

Merge branch 'jk/interpret-branch-name'

2017-03-14T22:23:18Z

"git branch @" created refs/heads/@ as a branch, and in general the code that handled @{-1} and @{upstream} was a bit too loose in disambiguating. * jk/interpret-branch-name: checkout: restrict @-expansions when finding branch strbuf_check_ref_format(): expand only local branches branch: restrict @-expansions when deleting t3204: test git-branch @-expansion corner cases interpret_branch_name: allow callers to restrict expansions strbuf_branchname: add docstring strbuf_branchname: drop return value interpret_branch_name: move docstring to header file interpret_branch_name(): handle auto-namelen for @{-1}

Merge branch 'rs/strbuf-add-real-path'

2017-03-10T21:24:23Z

An helper function to make it easier to append the result from real_path() to a strbuf has been added. * rs/strbuf-add-real-path: strbuf: add strbuf_add_real_path() cocci: use ALLOC_ARRAY

interpret_branch_name: allow callers to restrict expansions

2017-03-02T19:05:04Z

The interpret_branch_name() function converts names like @{-1} and @{upstream} into branch names. The expanded ref names are not fully qualified, and may be outside of the refs/heads/ namespace (e.g., "@" expands to "HEAD", and "@{upstream}" is likely to be in "refs/remotes/"). This is OK for callers like dwim_ref() which are primarily interested in resolving the resulting name, no matter where it is. But callers like "git branch" treat the result as a branch name in refs/heads/. When we expand to a ref outside that namespace, the results are very confusing (e.g., "git branch @" tries to create refs/heads/HEAD, which is nonsense). Callers can't know from the returned string how the expansion happened (e.g., did the user really ask for a branch named "HEAD", or did we do a bogus expansion?). One fix would be to return some out-parameters describing the types of expansion that occurred. This has the benefit that the caller can generate precise error messages ("I understood @{upstream} to mean origin/master, but that is a remote tracking branch, so you cannot create it as a local name"). However, out-parameters make the function interface somewhat cumbersome. Instead, let's do the opposite: let the caller tell us which elements to expand. That's easier to pass in, and none of the callers give more precise error messages than "@{upstream} isn't a valid branch name" anyway (which should be sufficient). The strbuf_branchname() function needs a similar parameter, as most of the callers access interpret_branch_name() through it. We can break the callers down into two groups: 1. Callers that are happy with any kind of ref in the result. We pass "0" here, so they continue to work without restrictions. This includes merge_name(), the reflog handling in add_pending_object_with_path(), and substitute_branch_name(). This last is what powers dwim_ref(). 2. Callers that have funny corner cases (mostly in git-branch and git-checkout). These need to make use of the new parameter, but I've left them as "0" in this patch, and will address them individually in follow-on patches. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

strbuf_branchname: add docstring

2017-03-02T19:05:04Z

This function and its companion, strbuf_check_branch_ref(), did not have their purpose or semantics explained. Let's do so. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano