git/apply.c, branch gitk-resize-error

Merge branch 'ja/i18n-similar-messages'

2022-01-10T19:52:56Z

Similar message templates have been consolidated so that translators need to work on fewer number of messages. * ja/i18n-similar-messages: i18n: turn even more messages into "cannot be used together" ones i18n: ref-filter: factorize "%(foo) atom used without %(bar) atom" i18n: factorize "--foo outside a repository" i18n: refactor "unrecognized %(foo) argument" strings i18n: factorize "no directory given for --foo" i18n: factorize "--foo requires --bar" and the like i18n: tag.c factorize i18n strings i18n: standardize "cannot open" and "cannot read" i18n: turn "options are incompatible" into "cannot be used together" i18n: refactor "%s, %s and %s are mutually exclusive" i18n: refactor "foo and bar are mutually exclusive"

Merge branch 'jz/apply-3-corner-cases'

2022-01-10T19:52:53Z

"git apply --3way" bypasses the attempt to do a three-way application in more cases to address the regression caused by the recent change to use direct application as a fallback. * jz/apply-3-corner-cases: git-apply: skip threeway in add / rename cases

i18n: factorize "--foo outside a repository"

2022-01-05T21:31:00Z

Signed-off-by: Jean-Noël Avila Reviewed-by: Johannes Sixt Signed-off-by: Junio C Hamano

i18n: turn "options are incompatible" into "cannot be used together"

2022-01-05T21:29:23Z

Signed-off-by: Jean-Noël Avila Reviewed-by: Johannes Sixt Signed-off-by: Junio C Hamano

git-apply: skip threeway in add / rename cases

2021-12-20T20:39:45Z

Certain invocations of "git apply --3way" will attempt threeway and fail due to missing objects, even though git is able to fall back on apply_fragments and apply the patch successfully with a return value of 0. To fix, return early from try_threeway() in the following cases: - When the patch is a rename and no lines have changed. In this case, "git diff" doesn't record the blob info, so 3way is neither possible nor necessary. - When the patch is an addition and there is no add/add conflict, i.e. direct_to_threeway is false. In this case, threeway will fail since the preimage is not in cache, but isn't necessary anyway since there is no conflict. This fixes a few unecessary error messages when applying these kinds of patches with --3way. It also fixes a reported issue where applying a concatenation of several git produced patches will fail when those patches involve a deletion followed by creation of the same file. Add a test for this case too. (test provided by ) Signed-off-by: Jerry Zhang Signed-off-by: Junio C Hamano

git-apply: add --allow-empty flag

2021-12-13T22:30:25Z

Some users or scripts will pipe "git diff" output to "git apply" when replaying diffs or commits. In these cases, they will rely on the return value of "git apply" to know whether the diff was applied successfully. However, for empty commits, "git apply" will fail. This complicates scripts since they have to either buffer the diff and check its length, or run diff again with "exit-code", essentially doing the diff twice. Add the "--allow-empty" flag to "git apply" which allows it to handle both empty diffs and empty commits created by "git format-patch --always" by doing nothing and returning 0. Add tests for both with and without --allow-empty. Signed-off-by: Jerry Zhang Signed-off-by: Junio C Hamano

git-apply: add --quiet flag

2021-12-13T22:30:22Z

Replace OPT_VERBOSE with OPT_VERBOSITY. This adds a --quiet flag to "git apply" so the user can turn down the verbosity. Signed-off-by: Jerry Zhang Signed-off-by: Junio C Hamano

Merge branch 'jc/trivial-threeway-binary-merge'

2021-09-15T20:15:26Z

The "git apply -3" code path learned not to bother the lower level merge machinery when the three-way merge can be trivially resolved without the content level merge. * jc/trivial-threeway-binary-merge: apply: resolve trivial merge without hitting ll-merge with "--3way"

apply: resolve trivial merge without hitting ll-merge with "--3way"

2021-09-05T22:39:02Z

The ll_binary_merge() function assumes that the ancestor blob is different from either side of the new versions, and always fails the merge in conflict, unless -Xours or -Xtheirs is in effect. The normal "merge" machineries all resolve the trivial cases (e.g. if our side changed while their side did not, the result is ours) without triggering the file-level merge drivers, so the assumption is warranted. The code path in "git apply --3way", however, does not check for the trivial three-way merge situation and always calls the file-level merge drivers. This used to be perfectly OK back when we always first attempted a straight patch application and used the three-way code path only as a fallback. Any binary patch that can be applied as a trivial three-way merge (e.g. the patch is based exactly on the version we happen to have) would always cleanly apply, so the ll_binary_merge() that is not prepared to see the trivial case would not have to handle such a case. This no longer is true after we made "--3way" to mean "first try three-way and then fall back to straight application", and made "git apply -3" on a binary patch that is based on the current version no longer apply. Teach "git apply -3" to first check for the trivial merge cases and resolve them without hitting the file-level merge drivers. Signed-off-by: Jerry Zhang [jc: stolen tests from Jerry's patch] Signed-off-by: Junio C Hamano

Merge branch 'jk/apply-binary-hunk-parsing-fix'

2021-08-30T23:06:04Z

"git apply" miscounted the bytes and failed to read to the end of binary hunks. * jk/apply-binary-hunk-parsing-fix: apply: keep buffer/size pair in sync when parsing binary hunks