{"thread":{"id":"55754","subject":"Re: Formatting options are ignored when tracking functions","startedAt":"2021-05-22T01:58:36Z","lastAt":"2021-05-23T19:30:52Z","messageCount":5,"participants":["Philippe Blain","Bagas Sanjaya","Junio C Hamano","Felipe Contreras"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"425284","messageId":"EE7D39E6-D826-49E2-AD0E-090A83DFDEC1@gmail.com","threadId":"55754","inReplyTo":null,"subject":"Re: Formatting options are ignored when tracking functions","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2021-05-22T01:58:29Z","receivedAt":"2021-05-22T01:58:36Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Aidan,\n\nI believe this is working as advertised: only the first line of the commit message is shown. \nHowever as mentioned in the doc, the -L option also triggers patch output (-p), \nwhich you can omit if you explicitely add --no-patch (or shorter, -s). \n\nCheers,\nPhilippe. "},{"id":"425285","messageId":"b3035e1c-79fc-e285-fd0e-fca246ae5190@gmail.com","threadId":"55754","inReplyTo":"EE7D39E6-D826-49E2-AD0E-090A83DFDEC1@gmail.com","subject":"Re: Formatting options are ignored when tracking functions","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-05-22T03:55:14Z","receivedAt":"2021-05-22T03:55:21Z","isPatch":false,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"Hi Philippe,\n\nOn 22/05/21 08.58, Philippe Blain wrote:\n> Hi Aidan,\n> \n> I believe this is working as advertised: only the first line of the commit message is shown.\n> However as mentioned in the doc, the -L option also triggers patch output (-p),\n> which you can omit if you explicitely add --no-patch (or shorter, -s).\n> \n> Cheers,\n> Philippe.\n> \n\nSo the complete command for --oneline with -L in order to produce similar\noutput as other cases is `git log -L:: --oneline --no-patch`.\n\nI wonder if we can make --oneline implies --no-patch when -L is given,\nright?\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"},{"id":"425384","messageId":"xmqqczthnwuu.fsf@gitster.g","threadId":"55754","inReplyTo":"EE7D39E6-D826-49E2-AD0E-090A83DFDEC1@gmail.com","subject":"Re: Formatting options are ignored when tracking functions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-23T18:11:53Z","receivedAt":"2021-05-23T18:24:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philippe Blain writes:\n\n> I believe this is working as advertised: only the first line of\n> the commit message is shown.\n> However as mentioned in the doc, the -L option also triggers patch\n> output (-p), which you can omit if you explicitely add --no-patch\n> (or shorter, -s).\n\nHeh, I think \"working as advertised\" is not wrong per-se, but this\nfeels like a clear design mistake to me, at least at the UI level.\nAdmittedly, I've never used \"log -L\" in scripts and I've always used\nit interactively, in a context that I want to see the patch output,\nso this did not bother me so far.\n\nBut what commits -L decides have relevant changes and how these\ncommits are shown ought to be orthogonal. It surely may need to run\nthe content-level diff machinery to see if each commit affects the\narea of the code specified via the -L option, but just like \"git log\n-S\" can be used to find commits that change the number of\noccurrences of , and allows the users to choose to view them\nwith \"-p\" (but not force the --patch mode on), it should behave the\nsame way, I would think.\n\nWith a clear migration plan, we should be able to fix this over\ntime, I would think.\n\n"},{"id":"425385","messageId":"d801fe76-f40d-91ef-653e-925aba0fbdf4@gmail.com","threadId":"55754","inReplyTo":"xmqqczthnwuu.fsf@gitster.g","subject":"Re: Formatting options are ignored when tracking functions","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2021-05-23T18:20:58Z","receivedAt":"2021-05-23T18:24:57Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Junio,\n\nLe 2021-05-23 à 14:11, Junio C Hamano a écrit :\n> Philippe Blain writes:\n> \n>> I believe this is working as advertised: only the first line of\n>> the commit message is shown.\n>> However as mentioned in the doc, the -L option also triggers patch\n>> output (-p), which you can omit if you explicitely add --no-patch\n>> (or shorter, -s).\n> \n> Heh, I think \"working as advertised\" is not wrong per-se, but this\n> feels like a clear design mistake to me, at least at the UI level.\n> Admittedly, I've never used \"log -L\" in scripts and I've always used\n> it interactively, in a context that I want to see the patch output,\n> so this did not bother me so far.\n> \n> But what commits -L decides have relevant changes and how these\n> commits are shown ought to be orthogonal. It surely may need to run\n> the content-level diff machinery to see if each commit affects the\n> area of the code specified via the -L option, but just like \"git log\n> -S\" can be used to find commits that change the number of\n> occurrences of , and allows the users to choose to view them\n> with \"-p\" (but not force the --patch mode on), it should behave the\n> same way, I would think.\n> \n> With a clear migration plan, we should be able to fix this over\n> time, I would think.\n> \n\nI agree with that. I was just pointing out that it does work as the doc\nsays it should work, without implying anything about what should be the\nbehaviour in an ideal world.\n\nIn fact in an ideal world, '-L' would support all \"kinds\" of diff output,\ni.e. --stat, --summary, etc.\n\nI do not have a clear opinion on a migration path; if consensus can be reached\nthat not implying '--patch' is a better behaviour, then changing the behaviour\nwould be OK. If some people use scripts that parse 'git log -L' ouptut expecting\nthat '-p' is implied, I would expect it's pretty easy to notice the breakage and\nadd the now-required switch... but I'll let others be the judge of that.\n\nCheers,\n\nPhilippe.\n"},{"id":"425387","messageId":"60aaacdb6a7da_53920893@natae.notmuch","threadId":"55754","inReplyTo":"d801fe76-f40d-91ef-653e-925aba0fbdf4@gmail.com","subject":"Re: Formatting options are ignored when tracking functions","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-23T19:28:27Z","receivedAt":"2021-05-23T19:30:52Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Philippe Blain wrote:\n> Le 2021-05-23 à 14:11, Junio C Hamano a écrit :\n> I do not have a clear opinion on a migration path; if consensus can be reached\n> that not implying '--patch' is a better behaviour, then changing the behaviour\n> would be OK. If some people use scripts that parse 'git log -L' ouptut expecting\n> that '-p' is implied, I would expect it's pretty easy to notice the breakage and\n> add the now-required switch... but I'll let others be the judge of that.\n\nI agree; it should be easy to notice the breakage. I don't think any\nmigration path would help, we should just switch. But the git project\nhas a tendency to worry about hypothetical users.\n\nThis is the only thing I can imagine doing for those users:\n\n--- a/builtin/log.c\n+++ b/builtin/log.c\n@@ -262,8 +262,13 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix,\n load_ref_decorations(&decoration_filter, decoration_style);\n }\n \n- if (rev->line_level_traverse)\n+ if (rev->line_level_traverse) {\n+ if (!(rev->diffopt.output_format & DIFF_FORMAT_NO_OUTPUT) && !rev->diff) {\n+ advise(\"In the future you will need to specify --patch. Hit Enter to proceed.\");\n+ getc(stdin);\n+ }\n line_log_init(rev, line_cb.prefix, &line_cb.args);\n+ }\n \n setup_pager();\n }\n\n-- \nFelipe Contreras"}]}