Hi Eyvind, Eyvind Bernhardsen wrote: > Here's a new version of the merge normalization series that renames the > configuration variable. Since "merge.renormalize" got the best > response, I went with that. I have no idea how the following branch happened in my local git tree, but it’s here now so maybe it’s worth something. Somehow I got the idea that the merge_renormalize variable was a nice short-term protection but long-term scary, and so a few patches emerged to banish it. Please let me emphasize that in their current form I do not think these patches should be very usable. But for later, they tell a nice story. The idea is that the "merge.renormalize" is not really about the behavior of the "git merge" command but about the merge-recursive driver; and so it should be usable everywhere else that driver is used, too. So in an ideal world, you would be able to, e.g.: git checkout -m -Xrenormalize otherbranch or git revert -Xrenormalize otherpatch or git pull --rebase -Xrenormalize Of course, the plumbing is not all there yet; many commands that use merge drivers cannot pass through arbitrary options through yet. Well, enough talking. Here are the patches; what do you think? Patch 1 teaches blob_unchanged() to stop paying attention to the merge_recursive variable. It uses a parameter instead. So from then on, it can watch, bemused, a neutral party. Patch 2 adds and respects a renormalize option in the merge_options struct. It defaults to the value of the merge_recursive global to save callers (in particular, "git merge") the pain of adjusting. Patch 3 lets ll_merge merge callers decide whether to renormalize, too. Most callers never renormalize, since they are not "git merge" (and this is noted in new comments). Patch 4 is a sort of a digression. It makes "git rerere" produce nice help output with the "git rerere -h" option. Patch 5 lets rerere callers decide whether to renormalize, too. Most callers never renormalize. But looking at that patch reveals a serious problem: there are all kinds of other merge options (e.g., -Xsubtree) that rerere callers are unable to control. Following the principle that scripted users should have about as much power as internal ones, patch 5 reluctantly exposes the renormalize option to rerere as a new --renormalize option. It should be -Xrenormalize instead. Patch 6 eliminates the merge_recursive global once and for all, by teaching merge_recursive callers to set the renormalize merge option appropriately (and removing the backward-compatibility default). Callers that are not "git merge" still never use renormalize. Following the principle that scripted users should have as much power as internal ones, it also exposes the nice interface of an -Xrenormalize option. Some redundancy between builtin/merge and builtin/merge-recursive is noticed but left for another topic. Jonathan Nieder (6): merge-trees: push choice to renormalize away from low level merge-trees: let caller decide whether to renormalize ll-merge: let caller decide whether to renormalize rerere: migrate to parse-options API rerere: let caller decide whether to renormalize merge-recursive: add -Xrenormalize option Documentation/merge-strategies.txt | 8 +++++ builtin/checkout.c | 13 ++++++++- builtin/commit.c | 4 ++ builtin/merge-recursive.c | 2 + builtin/merge.c | 24 +++++++++++---- builtin/rerere.c | 56 ++++++++++++++++++++--------------- builtin/revert.c | 18 ++++++++++- cache.h | 1 - environment.c | 1 - ll-merge.c | 4 +- ll-merge.h | 2 +- merge-file.c | 2 +- merge-recursive.c | 11 ++++-- merge-recursive.h | 1 + rerere.c | 20 ++++++++---- rerere.h | 1 + 16 files changed, 117 insertions(+), 51 deletions(-) -- 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