]> git.ipfire.org Git - thirdparty/git.git/commit
git-apply: allow simultaneous --cached and --3way options
authorJerry Zhang <jerry@skydio.com>
Thu, 8 Apr 2021 02:13:44 +0000 (19:13 -0700)
committerJunio C Hamano <gitster@pobox.com>
Thu, 8 Apr 2021 05:20:33 +0000 (22:20 -0700)
commitc0c2a37ac2b9338c3a93340cbcbab69690da4df0
tree246b559d28fd4d7b0c67b38a678bad683a93c59e
parent923cd87ac8550a8e277bfeb19198a11b6a8ed854
git-apply: allow simultaneous --cached and --3way options

"git apply" does not allow "--cached" and "--3way" to be used
together, since "--3way" writes conflict markers into the working
tree.

Allow "git apply" to accept "--cached" and "--3way" at the same
time.  When a single file auto-resolves cleanly, the result is
placed in the index at stage #0 and the command exits with 0 status.

For a file that has a conflict which cannot be cleanly
auto-resolved, the original contents from common ancestor (stage
conflict at the content level, and the command exists with non-zero
status, because there is no place (like the working tree) to leave a
half-resolved merge for the user to resolve.

The user can use `git diff` to view the contents of the conflict, or
`git checkout -m -- .` to regenerate the conflict markers in the
working directory.

Don't attempt rerere in this case since it depends on conflict
markers written to file for its database storage and lookup. There
would be two main changes required to get rerere working:

1. Allow the rerere api to accept in memory object rather than
   files, which would allow us to pass in the conflict markers
   contained in the result from ll_merge().

2. Rerere can't write to the working directory, so it would have to
   apply the result to cache stage #0 directly. A flag would be
   needed to control this.

Signed-off-by: Jerry Zhang <jerry@skydio.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/git-apply.txt
apply.c
t/t4108-apply-threeway.sh