git/apply.c, branch v2.13.2

Merge branch 'jc/apply-fix-mismerge' into maint

2017-06-04T01:20:59Z

Mismerge fix. * jc/apply-fix-mismerge: apply.c: fix whitespace-only mismerge

apply.c: fix whitespace-only mismerge

2017-05-09T02:33:31Z

4af9a7d3 ("Merge branch 'bc/object-id'", 2016-09-19) involved merging a lot of changes made to builtin/apply.c on the side branch manually to apply.c as an intervening commit 13b5af22 ("apply: move libified code from builtin/apply.c to apply.{c,h}", 2016-04-22) moved a lot of the lines changed on the side branch to a different file apply.c at the top-level, requiring manual patching of it. Apparently, the maintainer screwed up and made the code indent in a funny way while doing so. Reported-by: Stefan Beller 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

apply: use SWAP macro

2017-01-30T22:07:52Z

Use the exported macro SWAP instead of the file-scoped macro swap and remove the latter's definition. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

hold_locked_index(): align error handling with hold_lockfile_for_update()

2016-12-07T19:31:59Z

Callers of the hold_locked_index() function pass 0 when they want to prepare to write a new version of the index file without wishing to die or emit an error message when the request fails (e.g. somebody else already held the lock), and pass 1 when they want the call to die upon failure. This option is called LOCK_DIE_ON_ERROR by the underlying lockfile API, and the hold_locked_index() function translates the paramter to LOCK_DIE_ON_ERROR when calling the hold_lock_file_for_update(). Replace these hardcoded '1' with LOCK_DIE_ON_ERROR and stop translating. Callers other than the ones that are replaced with this change pass '0' to the function; no behaviour change is intended with this patch. Signed-off-by: Junio C Hamano --- Among the callers of hold_locked_index() that passes 0: - diff.c::refresh_index_quietly() at the end of "git diff" is an opportunistic update; it leaks the lockfile structure but it is just before the program exits and nobody should care. - builtin/describe.c::cmd_describe(), builtin/commit.c::cmd_status(), sequencer.c::read_and_refresh_cache() are all opportunistic updates and they are OK. - builtin/update-index.c::cmd_update_index() takes a lock upfront but we may end up not needing to update the index (i.e. the entries may be fully up-to-date), in which case we do not need to issue an error upon failure to acquire the lock. We do diagnose and die if we indeed need to update, so it is OK. - wt-status.c::require_clean_work_tree() IS BUGGY. It asks silence, does not check the returned value. Compare with callsites like cmd_describe() and cmd_status() to notice that it is wrong to call update_index_if_able() unconditionally.

i18n: apply: mark error message for translation

2016-10-17T21:51:42Z

Update test to reflect changes. Signed-off-by: Vasco Almeida Signed-off-by: Junio C Hamano

i18n: apply: mark error messages for translation

2016-10-14T17:53:58Z

Mark error messages for translation passed to error() and die() functions. Signed-off-by: Vasco Almeida Signed-off-by: Junio C Hamano

i18n: apply: mark info messages for translation

2016-10-14T17:53:51Z

Mark messages for translation printed to stderr. Signed-off-by: Vasco Almeida Signed-off-by: Junio C Hamano

i18n: apply: mark plural string for translation

2016-10-14T17:53:49Z

Mark plural string for translation using Q_(). Signed-off-by: Vasco Almeida Signed-off-by: Junio C Hamano