{"thread":{"id":"16805","subject":"RFC: Change whatchanged to report changes from merges by default?","startedAt":"2008-12-20T10:42:32Z","lastAt":"2008-12-20T20:21:09Z","messageCount":4,"participants":["Mark Burton","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"98426","messageId":"20081220104232.5ff1b7c0@crow","threadId":"16805","inReplyTo":null,"subject":"RFC: Change whatchanged to report changes from merges by default?","fromName":"Mark Burton","fromEmail":"markb@ordern.com","sentAt":"2008-12-20T10:42:32Z","receivedAt":"2008-12-20T10:42:32Z","isPatch":false,"sender":{"key":"markb@ordern.com","avatar":null},"body":"\nHi,\n\nIs it just an accident of history or by design that whatchanged\nrequires the -m option to show changes introduced by merges but\ndiff and git log show those changes without requiring any extra\noptions?\n\nWould it not make more sense to have git whatchanged show the changes\nintroduced by merges by default and then people can use the (already\nsupported) --no-merges option to suppress that behaviour?\n\nIt appears that just setting rev.ignore_merges to 0 in cmd_whatchanged()\nwould do the trick. Shall I submit a patch?\n\nMark\n"},{"id":"98442","messageId":"20081220172252.6469d9b7@crow","threadId":"16805","inReplyTo":"20081220104232.5ff1b7c0@crow","subject":"Re: RFC: Change whatchanged to report changes from merges by default?","fromName":"Mark Burton","fromEmail":"markb@ordern.com","sentAt":"2008-12-20T17:22:52Z","receivedAt":"2008-12-20T17:22:52Z","isPatch":false,"sender":{"key":"markb@ordern.com","avatar":null},"body":"\nHi,\n\nOn further studying, I see that 1aec7917dc (git log: don't do merge\ndiffs by default) makes git log only show the log message by default\nfor merges. OK, no problem with that. \n\nHowever, in my mind, whatchanged is misleading when it doesn't output\nanything (by default) for merges because, in my mind, that implies that\nnothing has changed when, in fact, whole heaps of stuff could have been\nmerged in. So, if you forget to add the -m option, whatchanged will silently\nignore all the merged stuff and leave the poor user in the dark.\n\nSo, if changing the default behaviour is acceptable, I still think it would\nbe better if ignore_merges is set to 0 in cmd_whatchanged() but I guess an\nalternative would be to set always_show_header, instead.\n\nAny thoughts?\n\nCheers,\n\nMark\n"},{"id":"98446","messageId":"7vvdtewqvy.fsf@gitster.siamese.dyndns.org","threadId":"16805","inReplyTo":"20081220104232.5ff1b7c0@crow","subject":"Re: RFC: Change whatchanged to report changes from merges by default?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-20T20:09:05Z","receivedAt":"2008-12-20T20:09:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mark Burton <markb@ordern.com> writes:\n\n> Is it just an accident of history or by design that whatchanged\n> requires the -m option to show changes introduced by merges but\n> diff and git log show those changes without requiring any extra\n> options?\n\nMostly personal preference and inertia..\n\nI personally do not see any reason for anybody to use whatchanged (what a\nlong single-word to type!) since around git version v1.0.0 or so.  Back\nthen, whatchanged was a good way to satisfy \"I want a quick sanity check,\nbut I want to see a bit more than just names of files to assure me.  But I\nwant to get that without actually running the diffs or stats because I\nconsider that anything that takes more than half a second is too\nexpensive.\"  But ever since we made the diff generation built-in, the\nperformance objection ceased to be an issue.  These days I'd imagine that\n\"log --name-only\" or even \"log --stat\" would be perfectly acceptable and\neasier to explain alternative, especially if you happen to be a very early\nadopter whose fingers are trained to type \"whatchanged\".\n\nIOW, I consider \"whatchanged\" a command that is kept only for old timers'\nsake.  There is no reason to promote it, but there is no reason to\ndeprecate it, either.  Which means the answer to this question...\n\n> Would it not make more sense to have git whatchanged show the changes\n> introduced by merges by default and then people can use the (already\n> supported) --no-merges option to suppress that behaviour?\n\n... is a NO spelled in capital letters.\n"},{"id":"98453","messageId":"20081220202109.336d0a5e@crow","threadId":"16805","inReplyTo":"7vvdtewqvy.fsf@gitster.siamese.dyndns.org","subject":"Re: RFC: Change whatchanged to report changes from merges by default?","fromName":"Mark Burton","fromEmail":"markb@ordern.com","sentAt":"2008-12-20T20:21:09Z","receivedAt":"2008-12-20T20:21:09Z","isPatch":false,"sender":{"key":"markb@ordern.com","avatar":null},"body":"\nOn Sat, 20 Dec 2008 12:09:05 -0800\nJunio C Hamano <gitster@pobox.com> wrote:\n\n> IOW, I consider \"whatchanged\" a command that is kept only for old timers'\n> sake.  There is no reason to promote it, but there is no reason to\n> deprecate it, either.  Which means the answer to this question...\n> \n> > Would it not make more sense to have git whatchanged show the changes\n> > introduced by merges by default and then people can use the (already\n> > supported) --no-merges option to suppress that behaviour?  \n> \n> ... is a NO spelled in capital letters.\n\nOK (spelled in capital letters), I won't submit the patch.\n\nCheers,\n\nMark\n"}]}