git/builtin/worktree.c, branch v2.13.2

show_worktree(): plug memory leak

2017-05-08T03:18:20Z

The buffer allocated by shorten_unambiguous_ref() needs to be released. Discovered by Coverity. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'nd/worktree-add-lock'

2017-04-26T06:39:12Z

Allow to lock a worktree immediately after it's created. This helps prevent a race between "git worktree add; git worktree lock" and "git worktree prune". * nd/worktree-add-lock: worktree add: add --lock option

Merge branch 'jk/war-on-git-path'

2017-04-26T06:39:08Z

While handy, "git_path()" is a dangerous function to use as a callsite that uses it safely one day can be broken by changes to other code that calls it. Reduction of its use continues. * jk/war-on-git-path: am: drop "dir" parameter from am_state_init replace strbuf_addstr(git_path()) with git_path_buf() replace xstrdup(git_path(...)) with git_pathdup(...) use git_path_* helper functions branch: add edit_description() helper bisect: add git_path_bisect_terms helper

replace strbuf_addstr(git_path()) with git_path_buf()

2017-04-21T04:04:20Z

Writing directly into the strbuf avoids a useless copy of the data, and dropping calls to git_path() makes it easier to audit for dangerous calls. Note that git_path() does an implicit strbuf_reset(), but in each of these cases we were either already doing that reset, or writing into a fresh strbuf anyway. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

worktree add: add --lock option

2017-04-21T00:59:02Z

As explained in the document. This option has an advantage over the command sequence "git worktree add && git worktree lock": there will be no gap that somebody can accidentally "prune" the new worktree (or soon, explicitly "worktree remove" it). "worktree add" does keep a lock on while it's preparing the worktree. If --lock is specified, this lock remains after the worktree is created. Suggested-by: David Taylor Signed-off-by: Nguyễn Thái Ngọc Duy Helped-by: Jeff King Signed-off-by: Junio C Hamano

prefix_filename: return newly allocated string

2017-03-21T18:18:41Z

The prefix_filename() function returns a pointer to static storage, which makes it easy to use dangerously. We already fixed one buggy caller in hash-object recently, and the calls in apply.c are suspicious (I didn't dig in enough to confirm that there is a bug, but we call the function once in apply_all_patches() and then again indirectly from parse_chunk()). Let's make it harder to get wrong by allocating the return value. For simplicity, we'll do this even when the prefix is empty (and we could just return the original file pointer). That will cause us to allocate sometimes when we wouldn't otherwise need to, but this function isn't called in performance critical code-paths (and it already _might_ allocate on any given call, so a caller that cares about performance is questionable anyway). The downside is that the callers need to remember to free() the result to avoid leaking. Most of them already used xstrdup() on the result, so we know they are OK. The remainder have been converted to use free() as appropriate. I considered retaining a prefix_filename_unsafe() for cases where we know the static lifetime is OK (and handling the cleanup is awkward). This is only a handful of cases, though, and it's not worth the mental energy in worrying about whether the "unsafe" variant is OK to use in any situation. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

prefix_filename: drop length parameter

2017-03-21T18:12:53Z

This function takes the prefix as a ptr/len pair, but in every caller the length is exactly strlen(ptr). Let's simplify the interface and just take the string. This saves callers specifying it (and in some cases handling a NULL prefix). In a handful of cases we had the length already without calling strlen, so this is technically slower. But it's not likely to matter (after all, if the prefix is non-empty we'll allocate and copy it into a buffer anyway). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'ps/worktree-prune-help-fix'

2017-02-10T20:52:25Z

Incorrect usage help message for "git worktree prune" has been fixed. * ps/worktree-prune-help-fix: worktree: fix option descriptions for `prune`

worktree: fix option descriptions for `prune`

2017-02-06T18:59:25Z

The `verbose` and `expire` options of the `git worktree prune` subcommand have wrong descriptions in that they pretend to relate to objects. But as the git-worktree(1) correctly states, these options have nothing to do with objects but only with worktrees. Fix the description accordingly. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

worktree list: keep the list sorted

2016-11-28T21:18:51Z

It makes it easier to write tests for. But it should also be good for the user since locating a worktree by eye would be easier once they notice this. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano