git/apply.c, branch v2.16.2

Merge branch 'rs/apply-inaccurate-eof-with-incomplete-line'

2017-11-27T02:06:36Z

"git apply --inaccurate-eof" when used with "--ignore-space-change" triggered an internal sanity check, which has been fixed. * rs/apply-inaccurate-eof-with-incomplete-line: apply: update line lengths for --inaccurate-eof

Merge branch 'rs/apply-fuzzy-match-fix'

2017-11-21T05:07:52Z

A fix for an ancient bug in "git apply --ignore-space-change" codepath. * rs/apply-fuzzy-match-fix: apply: avoid out-of-bounds access in fuzzy_matchlines()

apply: update line lengths for --inaccurate-eof

2017-11-17T01:42:08Z

Some diff implementations don't report missing newlines at the end of files. Applying such a patch can cause a newline character to be added inadvertently. The option --inaccurate-eof of git apply can be used to remove trailing newlines if needed. apply_one_fragment() cuts it off from the buffers for preimage and postimage. Before it does, it builds an array with the lengths of each line for both. Make sure to update the length of the last line in these line info structures as well to keep them consistent with their respective buffer. Without this fix the added test fails; git apply dies and reports: fatal: BUG: caller miscounted postlen: asked 1, orig = 1, used = 2 That sanity check is only called if whitespace changes are ignored. Reported-by: Mahmoud Al-Qudsi Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

apply: avoid out-of-bounds access in fuzzy_matchlines()

2017-11-12T05:41:40Z

fuzzy_matchlines() uses a pointers to the first and last characters of two lines to keep track while matching them. This makes it impossible to deal with empty strings. It accesses characters before the start of empty lines. It can also access characters after the end when checking for trailing whitespace in the main loop. Avoid that by using pointers to the first character and the one *after* the last one. This is well-defined as long as the latter is not dereferenced. Basically rewrite the function based on that premise; it becomes much simpler as a result. There is no need to check for leading whitespace outside of the main loop anymore. Reported-by: Mahmoud Al-Qudsi Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

apply: remove `newfd` from `struct apply_state`

2017-10-06T01:07:18Z

Similar to a previous patch, we do not need to use `newfd` to signal that we have a lockfile to clean up. We can just unconditionally call `rollback_lock_file`. If we do not hold the lock, it will be a no-op. Where we check `newfd` to decide whether we need to take the lock, we can instead use `is_lock_file_locked()`. Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano

apply: move lockfile into `apply_state`

2017-10-06T01:07:18Z

We have two users of `struct apply_state` and the related functionality in apply.c. Each user sets up its `apply_state` by handing over a pointer to its static `lock_file`. (Before 076aa2cbd (tempfile: auto-allocate tempfiles on heap, 2017-09-05), we could never free lockfiles, so making them static was a reasonable approach.) Other than that, they never directly access their `lock_file`s, which are instead handled by the functionality in apply.c. To make life easier for the caller and to make it less tempting for a future caller to mess with the lock, make apply.c fully responsible for setting up the `lock_file`. As mentioned above, it is now safe to free a `lock_file`, so we can make the `struct apply_state` contain an actual `struct lock_file` instead of a pointer to one. The user in builtin/apply.c is rather simple. For builtin/am.c, we might worry that the lock state is actually meant to be inherited across calls. But the lock is only taken as `apply_all_patches()` executes, and code inspection shows that it will always be released. Alternatively, we can observe that the lock itself is never queried directly. When we decide whether we should lock, we check a related variable `newfd`. That variable is not inherited, so from the point of view of apply.c, the state machine really is reset with each call to `init_apply_state()`. (It would be a bug if `newfd` and the lock status were not in sync. The duplication of information in `newfd` and the lock will be addressed in the next patch.) Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano

consistently use "fallthrough" comments in switches

2017-09-22T03:49:57Z

Gcc 7 adds -Wimplicit-fallthrough, which can warn when a switch case falls through to the next case. The general idea is that the compiler can't tell if this was intentional or not, so you should annotate any intentional fall-throughs as such, leaving it to complain about any unannotated ones. There's a GNU __attribute__ which can be used for annotation, but of course we'd have to #ifdef it away on non-gcc compilers. Gcc will also recognize specially-formatted comments, which matches our current practice. Let's extend that practice to all of the unannotated sites (which I did look over and verify that they were behaving as intended). Ideally in each case we'd actually give some reasons in the comment about why we're falling through, or what we're falling through to. And gcc does support that with -Wimplicit-fallthrough=2, which relaxes the comment pattern matching to anything that contains "fallthrough" (or a variety of spelling variants). However, this isn't the default for -Wimplicit-fallthrough, nor for -Wextra. In the name of simplicity, it's probably better for us to support the default level, which requires "fallthrough" to be the only thing in the comment (modulo some window dressing like "else" and some punctuation; see the gcc manual for the complete set of patterns). This patch suppresses all warnings due to -Wimplicit-fallthrough. We might eventually want to add that to the DEVELOPER Makefile knob, but we should probably wait until gcc 7 is more widely adopted (since earlier versions will complain about the unknown warning type). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'rs/apply-epoch'

2017-09-10T08:08:25Z

Code simplification. * rs/apply-epoch: apply: remove epoch date from regex apply: check date of potential epoch timestamps first

Merge branch 'tb/apply-with-crlf'

2017-08-27T05:55:05Z

"git apply" that is used as a better "patch -p1" failed to apply a taken from a file with CRLF line endings to a file with CRLF line endings. The root cause was because it misused convert_to_git() that tried to do "safe-crlf" processing by looking at the index entry at the same path, which is a nonsense---in that mode, "apply" is not working on the data in (or derived from) the index at all. This has been fixed. * tb/apply-with-crlf: apply: file commited with CRLF should roundtrip diff and apply convert: add SAFE_CRLF_KEEP_CRLF

apply: remove epoch date from regex

2017-08-25T21:06:09Z

We check the date of epoch timestamp candidates already with starts_with(). Move beyond that part using skip_prefix() instead of checking it again using a regular expression. Also group the minutes part, so that we can access them using a substring match instead of using a magic number. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano