git/apply.h, branch v2.32.2

apply.h: include missing header

2019-09-28T05:04:16Z

When running `make hdr-check`, we got the following error messages: apply.h:146:22: error: use of undeclared identifier 'GIT_MAX_HEXSZ' char old_oid_prefix[GIT_MAX_HEXSZ + 1]; ^ apply.h:147:22: error: use of undeclared identifier 'GIT_MAX_HEXSZ' char new_oid_prefix[GIT_MAX_HEXSZ + 1]; ^ apply.h:151:33: error: array has incomplete element type 'struct object_id' struct object_id threeway_stage[3]; ^ ./strbuf.h:79:8: note: forward declaration of 'struct object_id' struct object_id; ^ 3 errors generated. make: *** [apply.hco] Error 1 Include the missing "hash.h" header to fix these errors. Signed-off-by: Denton Liu Signed-off-by: Junio C Hamano

apply: make parse_git_diff_header public

2019-07-11T21:29:27Z

Make 'parse_git_header()' (renamed to 'parse_git_diff_header()') a "public" function in apply.h, so we can re-use it in range-diff in a subsequent commit. We're renaming the function to make it clearer in other parts of the codebase that we're talking about a diff header and not just any header. Signed-off-by: Thomas Gummerer Signed-off-by: Junio C Hamano

Merge branch 'en/incl-forward-decl'

2018-08-20T19:41:32Z

Code hygiene improvement for the header files. * en/incl-forward-decl: Remove forward declaration of an enum compat/precompose_utf8.h: use more common include guard style urlmatch.h: fix include guard Move definition of enum branch_track from cache.h to branch.h alloc: make allocate_alloc_state and clear_alloc_state more consistent Add missing includes and forward declarations

Add missing includes and forward declarations

2018-08-15T18:52:09Z

I looped over the toplevel header files, creating a temporary two-line C program for each consisting of #include "git-compat-util.h" #include $HEADER This patch is the result of manually fixing errors in compiling those tiny programs. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

apply.c: make init_apply_state() take a struct repository

2018-08-13T21:14:44Z

We're moving away from the_index in this code. "struct index_state *" could be added to struct apply_state. But let's aim long term and put struct repository here instead so that we could even avoid more global states in the future. The index will be available via apply_state->repo->index. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

apply.h: drop extern on func declaration

2018-08-03T17:42:51Z

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

apply: add --intent-to-add

2018-05-29T03:42:30Z

Similar to 'git reset -N', this option makes 'git apply' automatically mark new files as intent-to-add so they are visible in the following 'git diff' command and could also be committed with 'git commit -a'. Signed-off-by: Nguyễn Thái Ngọc Duy 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

apply: remove prefix_length member from apply_state

2017-08-09T17:21:45Z

Use a NULL-and-NUL check to see if we have a prefix and consistently use C string functions on it instead of storing its length in a member of struct apply_state. This avoids strlen() calls and simplifies the code. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano