With finishing touches (mostly updates to in-code comments and log
messages). Previous ones were:
http://thread.gmane.org/gmane.comp.version-control.git/197538
http://thread.gmane.org/gmane.comp.version-control.git/197637
http://thread.gmane.org/gmane.comp.version-control.git/199936
Teach "git apply" a similar "-3"way merge fallback option with this
series, and you can now apply your patches without having to reduce
context. As it will leave the conflicted halves in the index and
let you manually resolve conflicts in the working tree, "--3way"
implies "--index", and cannot be used with "--cached" or "--reject".
I've been using this in my regular workflow, which involves a fair
amount of "git diff >P.diff" later followed by "git apply P.diff"
when flipping patches in topics around, and things seem to work OK.
Junio C Hamano (19):
apply: fix an incomplete comment in check_patch()
apply: a bit more comments on PATH_TO_BE_DELETED
apply: clear_image() clears things a bit more
apply: refactor read_file_or_gitlink()
apply: factor out checkout_target() helper function
apply: split load_preimage() helper function out
apply: refactor "previous patch" logic
apply: further split load_preimage()
apply: move check_to_create_blob() closer to its sole caller
apply: move "already exists" logic to check_to_create()
apply: accept -3/--3way command line option
apply: fall back on three-way merge
apply: plug the three-way merge logic in
apply: move verify_index_match() higher
apply: --3way with add/add conflict
apply: register conflicted stages to the index
apply: allow rerere() to work on --3way results
apply: document --3way option
apply: tests for the --3way option
Documentation/git-apply.txt | 11 +-
builtin/apply.c | 557 ++++++++++++++++++++++++++++++++++----------
t/t4108-apply-threeway.sh | 157 +++++++++++++
t/t4117-apply-reject.sh | 8 +
4 files changed, 615 insertions(+), 118 deletions(-)
create mode 100755 t/t4108-apply-threeway.sh
--
1.7.11.1.294.g68a9409
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
