git/apply.c, branch v2.20.2

Merge branch 'js/apply-recount-allow-noop'

2018-11-18T09:23:56Z

When editing a patch in a "git add -i" session, a hunk could be made to no-op. The "git apply" program used to reject a patch with such a no-op hunk to catch user mistakes, but it is now updated to explicitly allow a no-op hunk in an edited patch. * js/apply-recount-allow-noop: apply --recount: allow "no-op hunks"

apply --recount: allow "no-op hunks"

2018-11-13T04:02:52Z

When editing patches e.g. in `git add -e`, it is quite common that a hunk ends up having no -/+ lines, i.e. it is now supposed to do nothing. This use case was broken by ad6e8ed37bc1 (apply: reject a hunk that does not do anything, 2015-06-01) with the good intention of catching a very real, different issue in hand-edited patches. So let's use the `--recount` option as the tell-tale whether the user would actually be okay with no-op hunks. Add a test case to make sure that this use case does not regress again. Signed-off-by: Johannes Schindelin Reviewed-by: Josh Steadmon Signed-off-by: Junio C Hamano

assert NOARG/NONEG behavior of parse-options callbacks

2018-11-06T03:56:29Z

When we define a parse-options callback, the flags we put in the option struct must match what the callback expects. For example, a callback which does not handle the "unset" parameter should only be used with PARSE_OPT_NONEG. But since the callback and the option struct are not defined next to each other, it's easy to get this wrong (as earlier patches in this series show). Fortunately, the compiler can help us here: compiling with -Wunused-parameters can show us which callbacks ignore their "unset" parameters (and likewise, ones that ignore "arg" expect to be triggered with PARSE_OPT_NOARG). But after we've inspected a callback and determined that all of its callers use the right flags, what do we do next? We'd like to silence the compiler warning, but do so in a way that will catch any wrong calls in the future. We can do that by actually checking those variables and asserting that they match our expectations. Because this is such a common pattern, we'll introduce some helper macros. The resulting messages aren't as descriptive as we could make them, but the file/line information from BUG() is enough to identify the problem (and anyway, the point is that these should never be seen). Each of the annotated callbacks in this patch triggers -Wunused-parameters, and was manually inspected to make sure all callers use the correct options (so none of these BUGs should be triggerable). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

apply: return -1 from option callback instead of calling exit(1)

2018-11-06T03:55:36Z

The option callback for "apply --whitespace" exits with status "1" on error. It makes more sense for it to just return an error to parse-options. That code will exit, too, but it will use status "129" that is customary for option errors. The exit() dates back to aaf6c447aa (builtin/apply: make parse_whitespace_option() return -1 instead of die()ing, 2016-08-08). That commit gives no reason why we'd prefer the current exit status (it looks like it was just bumping the "die" up a level in the callstack, but did not go as far as it could have). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

apply: mark include/exclude options as NONEG

2018-11-06T03:55:35Z

The options callback for "git apply --no-include" is not ready to handle the "unset" parameter, and as a result will segfault when it adds a NULL argument to the include list (likewise for "--no-exclude"). In theory this might be used to clear the list, but since both "--include" and "--exclude" add to the same list, it's not immediately obvious what the semantics should be. Let's punt on that for now and just disallow the broken options. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'bc/hash-transition-part-15'

2018-10-30T06:43:42Z

More codepaths are moving away from hardcoded hash sizes. * bc/hash-transition-part-15: rerere: convert to use the_hash_algo submodule: make zero-oid comparison hash function agnostic apply: rename new_sha1_prefix and old_sha1_prefix apply: replace hard-coded constants tag: express constant in terms of the_hash_algo transport: use parse_oid_hex instead of a constant upload-pack: express constants in terms of the_hash_algo refs/packed-backend: express constants using the_hash_algo packfile: express constants in terms of the_hash_algo pack-revindex: express constants in terms of the_hash_algo builtin/fetch-pack: remove constants with parse_oid_hex builtin/mktree: remove hard-coded constant builtin/repack: replace hard-coded constants pack-bitmap-write: use GIT_MAX_RAWSZ for allocation object_id.cocci: match only expressions of type 'struct object_id'

apply: rename new_sha1_prefix and old_sha1_prefix

2018-10-15T03:53:16Z

Rename these structure members to "new_oid_prefix" and "old_oid_prefix". Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

apply: replace hard-coded constants

2018-10-15T03:53:16Z

Replace several 40-based constants with references to GIT_MAX_HEXSZ or the_hash_algo, as appropriate. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

ws.c: remove implicit dependency on the_index

2018-09-21T16:51:18Z

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

rerere.c: remove implicit dependency on the_index

2018-09-21T16:48:11Z

The reason rerere(), rerere_forget() and rerere_remaining() take a struct repository instead of struct index_state is not obvious from the patch: Deep in update_paths() and find_conflict(), hold_locked_index() and read_index() are called. These functions assumes the index path at $GIT_DIR/index which is not always true when you take an arbitrary index state. Taking a repository will allow us to point to the right index path later when we replace them with repo_ versions. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano