Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > NEEDSWORK: this is a step in the wrong direction. rerere needs > an -s option to use an arbitrary merge strategy and a -X option to > pass arbitrary options to that driver. If you are talking about "rerere", I strongly disagree with that. 1. "-s" A "merge strategy" deals with the shape of the history (e.g. common ancestor selection or synthesis for the purpose of 3-way merge) and the shape of the trees (e.g. rename detection, subtree shifting). Starting from two commits, it decides, based on the shape of the history, what three trees your tree-level 3-way merge would operate on, and then based on the shape of the trees, decides the pairing of blobs to run the 3-way merge at the file-content level. When "rerere" is invoked, a strategy already has dealt with all of the above, and "rerere" only works on the (half-completed) result of that. 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" In the "merge -X<opt>" syntax, "-X" does not stand for "low level details"; it just means "eXternal callout". It is there just to tell the "merge" front-end "You may not understand this yourself, but the program you call does, so just pass it along". IOW, we want to be able to pass --<opt> through the frontend to the backend, without having to tell all the options any possible backends may know to the frontend. Just to make it easier to parse and tell which ones are the front-end options and which ones are not (for both machines and humans), we say -X<opt> to the frontend. Then "merge" turns that -X<opt> into "--<opt>" and give it to the strategy. 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. -- 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