Junio C Hamano wrote: > 1. "-s" [...] > When "rerere" is invoked, [...] > It is purely a three-way merge at the file-contents level and there is > no room for a "strategy" to get involved. It makes direct calls to > ll_merge() exactly for this reason. > > 2. "-X" [...] > A command that natively knows about an option is correct to take an > option as "--<option>", e.g. "merge--recursive --renormalize". You > trigger it by saying "merge -Xrenormalize" from the frontend. > > > To recap: it is absolutely the right thing to do to introduce a new > "rerere --renormalize" option, like your patch did. Doing anything else > IS a step in the wrong direction. Once you say it like that, it makes sense. :) Or rather, rerere should not take --renormalize at all. Patch 11 below has an explanation. Jonathan Nieder (12): t6038 (merge.renormalize): style nitpicks t6038 (merge.renormalize): try checkout -m and cherry-pick t6038 (merge.renormalize): check that it can be turned off merge-trees: push choice to renormalize away from low level merge-trees: let caller decide whether to renormalize Documentation/technical: document ll_merge ll-merge: make flag easier to populate ll-merge: let caller decide whether to renormalize t4200 (rerere): modernize style rerere: migrate to parse-options API rerere: never renormalize merge-recursive --renormalize Documentation/merge-strategies.txt | 12 + Documentation/technical/api-merge.txt | 73 ++++++ builtin/checkout.c | 11 + builtin/merge-recursive.c | 4 + builtin/merge.c | 19 ++- builtin/rerere.c | 52 +++-- builtin/revert.c | 7 + cache.h | 1 - environment.c | 1 - ll-merge.c | 11 +- ll-merge.h | 15 ++ merge-recursive.c | 14 +- merge-recursive.h | 1 + rerere.c | 4 + t/t4200-rerere.sh | 394 ++++++++++++++++++++++----------- t/t6038-merge-text-auto.sh | 143 +++++++++++- 16 files changed, 588 insertions(+), 174 deletions(-) create mode 100644 Documentation/technical/api-merge.txt -- 1.7.2.1.544.ga752d.dirty -- 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