git/strbuf.h, branch v2.13.2

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

strbuf_branchname: drop return value

2017-03-02T19:05:04Z

The return value from strbuf_branchname() is confusing and useless: it's 0 if the whole name was consumed by an @-mark, but otherwise is the length of the original name we fed. No callers actually look at the return value, so let's just get rid of it. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

strbuf: add strbuf_add_real_path()

2017-02-27T19:02:06Z

Add a function for appending the canonized absolute pathname of a given path to a strbuf. It keeps the existing contents intact, as expected of a function of the strbuf_add() family, while avoiding copying the result if the given strbuf is empty. It's more consistent with the rest of the strbuf API than strbuf_realpath(), which it's wrapping. Also add a semantic patch demonstrating its intended usage and apply it to the current tree. Using strbuf_add_real_path() instead of calling strbuf_addstr() and real_path() avoids an extra copy to a static buffer. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

use SWAP macro

2017-01-30T22:17:00Z

Apply the semantic patch swap.cocci to convert hand-rolled swaps to use the macro SWAP. The resulting code is shorter and easier to read, the object code is effectively unchanged. The patch for object.c had to be hand-edited in order to preserve the comment before the change; Coccinelle tried to eat it for some reason. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

link_alt_odb_entry: handle normalize_path errors

2016-10-10T20:52:36Z

When we add a new alternate to the list, we try to normalize out any redundant "..", etc. However, we do not look at the return value of normalize_path_copy(), and will happily continue with a path that could not be normalized. Worse, the normalizing process is done in-place, so we are left with whatever half-finished working state the normalizing function was in. Fortunately, this cannot cause us to read past the end of our buffer, as that working state will always leave the NUL from the original path in place. And we do tend to notice problems when we check is_directory() on the path. But you can see the nonsense that we feed to is_directory with an entry like: this/../../is/../../way/../../too/../../deep/../../to/../../resolve in your objects/info/alternates, which yields: error: object directory /to/e/deep/too/way//ects/this/../../is/../../way/../../too/../../deep/../../to/../../resolve does not exist; check .git/objects/info/alternates. We can easily fix this just by checking the return value. But that makes it hard to generate a good error message, since we're normalizing in-place and our input value has been overwritten by cruft. Instead, let's provide a strbuf helper that does an in-place normalize, but restores the original contents on error. This uses a second buffer under the hood, which is slightly less efficient, but this is not a performance-critical code path. The strbuf helper can also properly set the "len" parameter of the strbuf before returning. Just doing: normalize_path_copy(buf.buf, buf.buf); will shorten the string, but leave buf.len at the original length. That may be confusing to later code which uses the strbuf. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'rs/use-strbuf-addbuf'

2016-07-25T21:13:47Z

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