author | Junio C Hamano <gitster@pobox.com> | |
Mon, 1 Sep 2008 02:32:40 +0000 (19:32 -0700) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Mon, 1 Sep 2008 03:09:21 +0000 (20:09 -0700) | ||
commit | eac5a401512181cd315a1031af2b8a25430e335a | |
tree | 246e7b22c653c94af9a0cd615281b92e39fda902 | tree | snapshot |
parent | 0cf8581e330e7140c9f5c94a53d441187c0f8ff9 | commit | diff |
checkout --conflict=<style>: recreate merge in a non-default style
This new option does essentially the same thing as -m option when checking
unmerged paths out of the index, but it uses the specified style instead
of configured merge.conflictstyle.
Setting "merge.conflictstyle" to "diff3" is usually less useful than using
the default "merge" style, because the latter allows a conflict that
results by both sides changing the same region in a very similar way to
get simplified substancially by reducing the common lines. However, when
one side removed a group of lines (perhaps a function was moved to some
other file) while the other side modified it, the default "merge" style
does not give any clue as to why the hunk is left conflicting. You would
need the original to understand what is going on.
The recommended use would be not to set merge.conflictstyle variable so
that you would usually use the default "merge" style conflict, and when
the result in a path in a particular merge is too hard to understand, use
"git checkout --conflict=diff3 $path" to check it out with the original to
review what is going on.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This new option does essentially the same thing as -m option when checking
unmerged paths out of the index, but it uses the specified style instead
of configured merge.conflictstyle.
Setting "merge.conflictstyle" to "diff3" is usually less useful than using
the default "merge" style, because the latter allows a conflict that
results by both sides changing the same region in a very similar way to
get simplified substancially by reducing the common lines. However, when
one side removed a group of lines (perhaps a function was moved to some
other file) while the other side modified it, the default "merge" style
does not give any clue as to why the hunk is left conflicting. You would
need the original to understand what is going on.
The recommended use would be not to set merge.conflictstyle variable so
that you would usually use the default "merge" style conflict, and when
the result in a path in a particular merge is too hard to understand, use
"git checkout --conflict=diff3 $path" to check it out with the original to
review what is going on.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/git-checkout.txt | diff | blob | history | |
builtin-checkout.c | diff | blob | history | |
t/t7201-co.sh | diff | blob | history |