Junio C Hamano <gitster@xxxxxxxxx> writes: > Sergey Organov <sorganov@xxxxxxxxx> writes: > >> These patches introduce capability to configure the default format of >> output of diffs for merge commits by means of new log.diffMerges >> configuration variable. The default format is then used by -m, >> --diff-merges=m, and new --diff-merges=default options. >> >> In particular, >> >> git config log.diffMerges first-parent >> >> will change -m option format from "separate" to "first-parent" that >> will in turn cause, say, >> >> git show -m <merge_commit> >> >> to output diff to the first parent only, instead of appending >> typically large and surprising diff to the second parent at the end of >> the output. > > I think that it is a good goal to free a short-and-sweet "-m" from > getting tied forever to the current "two-tree diff for each of the > parent" (aka "separate"), and a configuration to change what the > "-m" option means would be a good approach to do so. It would help > the interactive use by human end-users, which is the point of having > short-and-sweet options. Existing scripts may depend on the current > behaviour, so the configuration cannot be introduced right away, but > over time they can be migrated to use the longer and more explicit > option "--diff-merges=separate". Yep, that's exactly the plan I have in mind. To tell the truth, I hope there are no scripts that use "git log -m -p", or "git show -m", but I do want to be on the safe side with it anyway, and then sometime in the future maybe we will be safe to change configuration default. > > But I do not see much point in adding the "--diff-merges=default". > Who is the target audience? Certainly not scripts that want to > avoid depending on the 'default' that can be different and easily > vary per user. There are 2 reasons to have "default": 1. --diff-merges=default and -m are not exact synonyms: unlike -m, --diff-merges=default (similar to other --diff-merges options) immediately enables diff output for merges, without -p, thus, for example, allowing to output diffs for merge commits only. The exact synonyms are rather --diff-merges=m and --diff-merges=default, and then we get to the next reason: 2. We have descriptive long name for every other option, and it'd be an exception if we'd have none for --diff-merges=m. In fact, it's --diff-merges=m that could have been removed, but it'd break resemblance with --cc and -c that both do have their --diff-merges=cc and --diff-merges=c counterparts. Overall, having "default" has both functional and consistency merits. > Or is the plan to deprecate and remove the short-and-sweet "-m" > option and standardize on "--diff-merges=<style>"? If so, such a > design makes sense from pureness and completeness standpoint, but I > am not sure if that is a good design for practical use. No, what I have in mind is resurrection of -m as more useful option, not removing it. Thanks, -- Sergey Organov
