git cherry-pick and git revert will present conflict hunks in output something like what ‘diff3 -m’ produces if the merge.conflictstyle configuration option is set to diff3. Unfortunately, some tools reportedly cannot parse the conflict hunks because of a small difference from diff3: diff3 -m includes a label for the merge base on the ||||||| line. Humans parsing the conflict hunks by hand might want to know what the common ancestor represents, too. So mark the start of the text from the parent of the commit being cherrypicked (resp. from the commit being reverted) with the label "parent". It would be nicer to use a more informative label, and that might happen in the future. git rerere will not have trouble parsing this output, since instead of looking for a newline, it looks for whitespace after the ||||||| marker. No other code in git tries to parse conflict hunks. Reported-by: Stefan Monnier <monnier@xxxxxxxxxxxxxxxx> Signed-off-by: Jonathan Nieder <jrnieder@xxxxxxxxx> --- In the revert case, this gives <<<<<<< HEAD foo ||||||| parent bar ======= baz >>>>>>> ab78c93 "Make some change we would like to revert" This is a bit misleading, since actually “baz” is from the commit to revert’s parent and “bar” is from the commit to revert. Probably the labels should be switched. I didn’t do this because it is late and it would have been a larger change from the current behavior. It also would be nice to suppress the ancestor and do a two-way merge when cherry-picking a root commit. I haven’t yet looked into how hard this would be. builtin/revert.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/builtin/revert.c b/builtin/revert.c index eff5268..a61dd9a 100644 --- a/builtin/revert.c +++ b/builtin/revert.c @@ -372,6 +372,7 @@ static int revert_or_cherry_pick(int argc, const char **argv) read_cache(); init_merge_options(&o); + o.ancestor = base ? "parent" : "(empty tree)"; o.branch1 = "HEAD"; o.branch2 = oneline; -- 1.7.0 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html