git/apply.c, branch v2.30.2

Merge branch 'ab/unreachable-break'

2020-12-18T23:15:18Z

Code clean-up. * ab/unreachable-break: style: do not "break" in switch() after "return"

style: do not "break" in switch() after "return"

2020-12-16T00:32:50Z

Remove this unreachable code. It was found by SunCC, it's found by a non-fatal warning emitted by SunCC. It's one of the things it's more vehement about than GCC & Clang. It complains about a lot of other similarly unreachable code, e.g. a BUG(...) without a "return", and a "return 0" after a long if/else, both of whom have "return" statements. Those are also genuine redundancies to a compiler, but arguably make the code a bit easier to read & less fragile to maintain. These return/break cases are just unnecessary however, and as seen here the surrounding code just did a plain "return" without a "break" already. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'mt/do-not-use-scld-in-working-tree'

2020-12-08T23:11:20Z

"git apply" adjusted the permission bits of working-tree files and directories according core.sharedRepository setting by mistake and for a long time, which has been corrected. * mt/do-not-use-scld-in-working-tree: apply: don't use core.sharedRepository to create working tree files

apply: don't use core.sharedRepository to create working tree files

2020-12-02T22:35:51Z

core.sharedRepository defines which permissions Git should set when creating files in $GIT_DIR, so that the repository may be shared with other users. But (in its current form) the setting shouldn't affect how files are created in the working tree. This is not respected by apply and am (which uses apply), when creating leading directories: $ cat d.patch diff --git a/d/f b/d/f new file mode 100644 index 0000000..e69de29 Apply without the setting: $ umask 0077 $ git apply d.patch $ ls -ld d drwx------ Apply with the setting: $ umask 0077 $ git -c core.sharedRepository=0770 apply d.patch $ ls -ld d drwxrws--- Only the leading directories are affected. That's because they are created with safe_create_leading_directories(), which calls adjust_shared_perm() to set the directories' permissions based on core.sharedRepository. To fix that, let's introduce a variant of this function that ignores the setting, and use it in apply. Also add a regression test and a note in the function documentation about the use of each variant according to the destination (working tree or git dir). Signed-off-by: Matheus Tavares Signed-off-by: Junio C Hamano

apply: when -R, also reverse list of sections

2020-10-20T22:21:41Z

A patch changing a symlink into a file is written with 2 sections (in the code, represented as "struct patch"): firstly, the deletion of the symlink, and secondly, the creation of the file. When applying that patch with -R, the sections are reversed, so we get: (1) creation of a symlink, then (2) deletion of a file. This causes an issue when the "deletion of a file" section is checked, because Git observes that the so-called file is not a file but a symlink, resulting in a "wrong type" error message. What we want is: (1) deletion of a file, then (2) creation of a symlink. In the code, this is reflected in the behavior of previous_patch() when invoked from check_preimage() when the deletion is checked. Creation then deletion means that when the deletion is checked, previous_patch() returns the creation section, triggering a mode conflict resulting in the "wrong type" error message. But deletion then creation means that when the deletion is checked, previous_patch() returns NULL, so the deletion mode is checked against lstat, which is what we want. There are also other ways a patch can contain 2 sections referencing the same file, for example, in 7a07841c0b ("git-apply: handle a patch that touches the same path more than once better", 2008-06-27). "git apply -R" fails in the same way, and this commit makes this case succeed. Therefore, when building the list of sections, build them in reverse order (by adding to the front of the list instead of the back) when -R is passed. Helped-by: Junio C Hamano Signed-off-by: Jonathan Tan Signed-off-by: Junio C Hamano

Merge branch 'jk/leakfix'

2020-08-27T21:04:49Z

Code clean-up. * jk/leakfix: submodule--helper: fix leak of core.worktree value config: fix leak in git_config_get_expiry_in_days() config: drop git_config_get_string_const() config: fix leaks from git_config_get_string_const() checkout: fix leak of non-existent branch names submodule--helper: use strbuf_release() to free strbufs clear_pattern_list(): clear embedded hashmaps

Merge branch 'rp/apply-cached-with-i-t-a'

2020-08-18T00:02:46Z

Recent versions of "git diff-files" shows a diff between the index and the working tree for "intent-to-add" paths as a "new file" patch; "git apply --cached" should be able to take "git diff-files" and should act as an equivalent to "git add" for the path, but the command failed to do so for such a path. * rp/apply-cached-with-i-t-a: t4140: test apply with i-t-a paths apply: make i-t-a entries never match worktree apply: allow "new file" patches on i-t-a entries

config: drop git_config_get_string_const()

2020-08-17T22:35:47Z

As evidenced by the leak fixes in the previous commit, the "const" in git_config_get_string_const() clearly misleads people into thinking that it does not allocate a copy of the string. We can fix this by renaming it, but it's easier still to just drop it. Of the four remaining callers: - The one in git_config_parse_expiry() still needs to allocate, since that's what its callers expect. We can just use the non-const version and cast our pointer. Slightly ugly, but the damage is contained in one spot. - The two in apply are writing to global "const char *" variables, and need to continue allocating. We often mark these as const because we assign default string literals to them. But in this case we don't do that, so we can just declare them as real "char *" pointers and use the non-const version. - The call in checkout doesn't actually need a copy; it can just use the non-allocating "tmp" version of the function. The function is also mentioned in the MyFirstContribution document. We can swap that call out for the non-allocating "tmp" variant, which fits well in the example given. We'll drop the "configset" and "repo" variants, as well (which are unused). Note that this frees up the "const" name, so we could rename the "tmp" variant back to that. But let's give some time for topics in flight to adapt to the new code before doing so (if we do it too soon, the function semantics will change but the compiler won't alert us). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

apply: make i-t-a entries never match worktree

2020-08-09T18:00:46Z

By definition, an intent-to-add index entry can never match the worktree, because worktrees have no concept of intent-to-add entries. Therefore, "apply --index" should always fail on intent-to-add paths. Because check_preimage() calls verify_index_match(), it already fails for patches other than creation patches, which check_preimage() ignores. This patch adds a check to check_preimage()'s rough equivalent for creation patches, check_to_create(). Helped-by: Junio C Hamano Signed-off-by: Raymond E. Pasco Signed-off-by: Junio C Hamano

apply: allow "new file" patches on i-t-a entries

2020-08-06T20:07:52Z

diff-files recently changed to treat changes to paths marked "intent to add" in the index as new file diffs rather than diffs from the empty blob. However, apply refuses to apply new file diffs on top of existing index entries, except in the case of renames. This causes "git add -p", which uses apply, to fail when attempting to stage hunks from a file when intent to add has been recorded. This changes the logic in check_to_create() which checks if an entry already exists in an index in two ways: first, we only search for an index entry at all if ok_if_exists is false; second, we check for the CE_INTENT_TO_ADD flag on any index entries we find and allow the apply to proceed if it is set. Helped-by: Junio C Hamano Signed-off-by: Raymond E. Pasco Signed-off-by: Junio C Hamano