{"thread":{"id":"45124","subject":"Incorrect pipe for git log graph when using --name-status option","startedAt":"2017-02-13T02:50:11Z","lastAt":"2017-02-13T21:51:14Z","messageCount":8,"participants":["hIpPy","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"311388","messageId":"CAM_JFCwYAKCWrHqCtcwid27V1HvhuSmp4QpbNpgyMzrzWUNYog@mail.gmail.com","threadId":"45124","inReplyTo":null,"subject":"Incorrect pipe for git log graph when using --name-status option","fromName":"hIpPy","fromEmail":"hippy2981@gmail.com","sentAt":"2017-02-13T02:49:23Z","receivedAt":"2017-02-13T02:50:11Z","isPatch":false,"sender":{"key":"hippy2981@gmail.com","avatar":"https://gravatar.com/avatar/00812eff6e91f90d2c1fe2faccef22d7c475073a1f5b7467152d5174fa61e0cb?d=mp&s=160"},"body":"The `git log` command with `graph` and pretty format works correctly\nas expected.\n\n$ git log --graph --pretty=format:'%h' -2\n* 714a14e\n* 87dce5f\n\n\nHowever, with `--name-status` option added, there is a pipe\nincorrectly placed after the commit hash (example below).\n\n$ git log --graph --pretty=format:'%h' -2 --name-status\n* 714a14e|\n| M README.md\n| A rm.Extensions/BitSet.cs\n| M rm.Extensions/Properties/AssemblyInfo.cs\n| M rm.Extensions/rm.Extensions.csproj\n| A rm.ExtensionsTest/BitSetTest.cs\n| M rm.ExtensionsTest/rm.ExtensionsTest.csproj\n\n* 87dce5f|\n| M rm.Extensions/GraphExtension.cs\n| M rm.Extensions/Wrapped.cs\n| M rm.Extensions/WrappedExtension.cs\n| M rm.Extensions/rm.Extensions.csproj\n\n\nIMHO, I think this is a bug. I think the correct output should be\nbelow.\n\n$ git log --graph --pretty=format:'%h' -2 --name-status\n* 714a14e\n| M README.md\n| A rm.Extensions/BitSet.cs\n| M rm.Extensions/Properties/AssemblyInfo.cs\n| M rm.Extensions/rm.Extensions.csproj\n\n| A rm.ExtensionsTest/BitSetTest.cs\n| M rm.ExtensionsTest/rm.ExtensionsTest.csproj\n|\n* 87dce5f\n| M rm.Extensions/GraphExtension.cs\n| M rm.Extensions/Wrapped.cs\n| M rm.Extensions/WrappedExtension.cs\n\n| M rm.Extensions/rm.Extensions.csproj\n\nI'm using this:\n\ngit version 2.11.0.windows.1\nGNU bash, version 4.3.46(2)-release (x86_64-pc-msys)\nWindows 8.1 64-bit\n\n\nThanks,\nRM\n"},{"id":"311421","messageId":"xmqqa89pevw0.fsf@gitster.mtv.corp.google.com","threadId":"45124","inReplyTo":"CAM_JFCwYAKCWrHqCtcwid27V1HvhuSmp4QpbNpgyMzrzWUNYog@mail.gmail.com","subject":"Re: Incorrect pipe for git log graph when using --name-status option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-02-13T19:25:03Z","receivedAt":"2017-02-13T19:25:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"hIpPy <hippy2981@gmail.com> writes:\n\n> The `git log` command with `graph` and pretty format works correctly\n> as expected.\n>\n> $ git log --graph --pretty=format:'%h' -2\n> * 714a14e\n> * 87dce5f\n>\n>\n> However, with `--name-status` option added, there is a pipe\n> incorrectly placed after the commit hash (example below).\n>\n> $ git log --graph --pretty=format:'%h' -2 --name-status\n> * 714a14e|\n> | M README.md\n\nIs it a --name-status, or is it your own custom format, that is\ncausing the above issue?\n\n - What happens if you stop using --pretty=format:%h and replace it\n   with something like --oneline?\n\n - What happens if you keep using --pretty=format:%h but replace\n   --name-status with something else, e.g. --raw or --stat?\n\n"},{"id":"311439","messageId":"CAM_JFCwN+o54mJ1XJ3rSKnXgPx3wt_i=fd8ZSGpcL-fSegQ=Ow@mail.gmail.com","threadId":"45124","inReplyTo":"xmqqa89pevw0.fsf@gitster.mtv.corp.google.com","subject":"Re: Incorrect pipe for git log graph when using --name-status option","fromName":"hIpPy","fromEmail":"hippy2981@gmail.com","sentAt":"2017-02-13T20:55:07Z","receivedAt":"2017-02-13T20:55:55Z","isPatch":false,"sender":{"key":"hippy2981@gmail.com","avatar":"https://gravatar.com/avatar/00812eff6e91f90d2c1fe2faccef22d7c475073a1f5b7467152d5174fa61e0cb?d=mp&s=160"},"body":"On Mon, Feb 13, 2017 at 11:25 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> hIpPy <hippy2981@gmail.com> writes:\n>\n>> The `git log` command with `graph` and pretty format works correctly\n>> as expected.\n>>\n>> $ git log --graph --pretty=format:'%h' -2\n>> * 714a14e\n>> * 87dce5f\n>>\n>>\n>> However, with `--name-status` option added, there is a pipe\n>> incorrectly placed after the commit hash (example below).\n>>\n>> $ git log --graph --pretty=format:'%h' -2 --name-status\n>> * 714a14e|\n>> | M README.md\n>\n> Is it a --name-status, or is it your own custom format, that is\n> causing the above issue?\n>\n>  - What happens if you stop using --pretty=format:%h and replace it\n>    with something like --oneline?\n>\n>  - What happens if you keep using --pretty=format:%h but replace\n>    --name-status with something else, e.g. --raw or --stat?\n>\n\n\n\n - What happens if you stop using --pretty=format:%h and replace it\n   with something like --oneline?\n--oneline works correctly as expected (example below).\n\n$ git log --graph --oneline -2 --name-status\n* bf7ace7daf (HEAD -> rm/option-for-name-status) wip: --ns for --name-status\n| M diff.c\n*   592e5c5bce (origin/master, origin/HEAD, master) Merge pull request\n#994 from jeffhostetler/jeffhostetler/fscache_nfd\n|\\\n\n\n - What happens if you keep using --pretty=format:%h but replace\n   --name-status with something else, e.g. --raw or --stat?\nI see the same issue with --raw and --stat (examples below).\n\n$ git log --graph --pretty=format:'%h' -2 --raw\n* bf7ace7daf|\n| :100644 100644 84dba60c40... 87dfabf4a9... M  diff.c\n\n*   592e5c5bce\n|\\\n\n$ git log --graph --pretty=format:'%h' -2 --stat\n* bf7ace7daf|\n|  diff.c | 2 +-\n|  1 file changed, 1 insertion(+), 1 deletion(-)\n\n*   592e5c5bce\n|\\\n\nI believe it's not my custom format that is causing the issue.\nI'm including this information that may not be relevant. I apologize\nin advance for that. I had simplified the custom format in my\nprevious email. For below custom format I still see the pipe\nincorrectly placed.\n\n$ git log --graph --date=relative --decorate --abbrev-commit\n--format=format:'%h - %aD (%ar)%d%n     %s - %an' -2 --name-status\n* bf7ace7daf - Mon, 6 Feb 2017 13:09:32 -0800 (7 days ago) (HEAD ->\nrm/option-for-name-status)\n|      wip: --ns for --name-status - Rishikesh Mandvikar|\n| M diff.c\n\n*   592e5c5bce - Wed, 1 Feb 2017 16:35:30 +0100 (12 days ago)\n(origin/master, origin/HEAD, master)\n|\\       Merge pull request #994 from\njeffhostetler/jeffhostetler/fscache_nfd - Johannes Schindelin\n\n\nIf I were to put a '%n' at the end (example below), the pipe is\ncorrectly placed with or without the --name-status option. But in\ncase of \"without the --name-status option\", there is an extra blank\nline. It seems that my custom format is requiring a %n at the end. I\nconsider my custom format as a --twoline option and I feel the\nbehavior should match --oneline when using options.\n\nWith --name-status: This works correctly.\n\n$ git log --graph --date=relative --decorate --abbrev-commit\n--format=format:'%h - %aD (%ar)%d%n     %s - %an%n' -2 --name-status\n* bf7ace7daf - Mon, 6 Feb 2017 13:09:32 -0800 (7 days ago) (HEAD ->\nrm/option-for-name-status)\n|      wip: --ns for --name-status - Rishikesh Mandvikar\n|\n| M diff.c\n|\n*   592e5c5bce - Wed, 1 Feb 2017 16:35:30 +0100 (12 days ago)\n(origin/master, origin/HEAD, master)\n|\\       Merge pull request #994 from\njeffhostetler/jeffhostetler/fscache_nfd - Johannes Schindelin\n\nWithout --name-status: This works but has extra blank line between\ncommits though.\n\n$ git log --graph --date=relative --decorate --abbrev-commit\n--format=format:'%h - %aD (%ar)%d%n     %s - %an%n' -2\n* bf7ace7daf - Mon, 6 Feb 2017 13:09:32 -0800 (7 days ago) (HEAD ->\nrm/option-for-name-status)\n|      wip: --ns for --name-status - Rishikesh Mandvikar\n|\n*   592e5c5bce - Wed, 1 Feb 2017 16:35:30 +0100 (12 days ago)\n(origin/master, origin/HEAD, master)\n|\\       Merge pull request #994 from\njeffhostetler/jeffhostetler/fscache_nfd - Johannes Schindelin\n\nI think that requiring to end custom formats with %n with options\nis not good. So I think this is a bug.\n\nThanks,\nRM\n"},{"id":"311446","messageId":"20170213211653.x3huwmzprvmm3yxj@sigill.intra.peff.net","threadId":"45124","inReplyTo":"CAM_JFCwN+o54mJ1XJ3rSKnXgPx3wt_i=fd8ZSGpcL-fSegQ=Ow@mail.gmail.com","subject":"Re: Incorrect pipe for git log graph when using --name-status option","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-13T21:16:53Z","receivedAt":"2017-02-13T21:17:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 13, 2017 at 12:55:07PM -0800, hIpPy wrote:\n\n> I think that requiring to end custom formats with %n with options\n> is not good. So I think this is a bug.\n\nYes, you don't normally need to do that.\n\nI think the problem is specifically related to the \"terminator\" versus\n\"separator\" semantics. Try:\n\n  git log --graph --name-status --pretty=format:%h\n\nversus:\n\n  git log --graph --name-status --pretty=tformat:%h\n\nThe latter works fine. The problem seems to happen with all diff\nformats, so I think the issue is that git is not aggressive enough about\ninserting the newline at the right spot when using separator mode.\n\n-Peff\n"},{"id":"311447","messageId":"xmqq37fhdc27.fsf@gitster.mtv.corp.google.com","threadId":"45124","inReplyTo":"20170213211653.x3huwmzprvmm3yxj@sigill.intra.peff.net","subject":"Re: Incorrect pipe for git log graph when using --name-status option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-02-13T21:18:40Z","receivedAt":"2017-02-13T21:18:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I think the problem is specifically related to the \"terminator\" versus\n> \"separator\" semantics. Try:\n>\n>   git log --graph --name-status --pretty=format:%h\n>\n> versus:\n>\n>   git log --graph --name-status --pretty=tformat:%h\n>\n> The latter works fine. The problem seems to happen with all diff\n> formats, so I think the issue is that git is not aggressive enough about\n> inserting the newline at the right spot when using separator mode.\n\nI guess that is one of the reasons why we made --format=%h a synonym\nto --pretty=tformat:%h and not --pretty=format:%h ;-)\n"},{"id":"311448","messageId":"20170213212734.howisucqqhusbglc@sigill.intra.peff.net","threadId":"45124","inReplyTo":"xmqq37fhdc27.fsf@gitster.mtv.corp.google.com","subject":"Re: Incorrect pipe for git log graph when using --name-status option","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-13T21:27:34Z","receivedAt":"2017-02-13T21:27:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 13, 2017 at 01:18:40PM -0800, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > I think the problem is specifically related to the \"terminator\" versus\n> > \"separator\" semantics. Try:\n> >\n> >   git log --graph --name-status --pretty=format:%h\n> >\n> > versus:\n> >\n> >   git log --graph --name-status --pretty=tformat:%h\n> >\n> > The latter works fine. The problem seems to happen with all diff\n> > formats, so I think the issue is that git is not aggressive enough about\n> > inserting the newline at the right spot when using separator mode.\n> \n> I guess that is one of the reasons why we made --format=%h a synonym\n> to --pretty=tformat:%h and not --pretty=format:%h ;-)\n\nYeah. I have never found \"--pretty=format\" to do what I want versus\ntformat. I wish we could just get rid of it, but I think it is likely to\nbe used as a plumbing interface.\n\nSo I think there probably _is_ a bug in it to be fixed, but my immediate\nresponse is \"don't ever use --pretty=format:\".\n\n-Peff\n"},{"id":"311451","messageId":"CAM_JFCzniePuqJTFOy-odLfuKcBjssh0zk3PFBsVcm6Ww6iW5w@mail.gmail.com","threadId":"45124","inReplyTo":"20170213212734.howisucqqhusbglc@sigill.intra.peff.net","subject":"Re: Incorrect pipe for git log graph when using --name-status option","fromName":"hIpPy","fromEmail":"hippy2981@gmail.com","sentAt":"2017-02-13T21:43:45Z","receivedAt":"2017-02-13T21:44:33Z","isPatch":false,"sender":{"key":"hippy2981@gmail.com","avatar":"https://gravatar.com/avatar/00812eff6e91f90d2c1fe2faccef22d7c475073a1f5b7467152d5174fa61e0cb?d=mp&s=160"},"body":"On Mon, Feb 13, 2017 at 1:27 PM, Jeff King <peff@peff.net> wrote:\n> On Mon, Feb 13, 2017 at 01:18:40PM -0800, Junio C Hamano wrote:\n>\n>> Jeff King <peff@peff.net> writes:\n>>\n>> > I think the problem is specifically related to the \"terminator\" versus\n>> > \"separator\" semantics. Try:\n>> >\n>> >   git log --graph --name-status --pretty=format:%h\n>> >\n>> > versus:\n>> >\n>> >   git log --graph --name-status --pretty=tformat:%h\n>> >\n>> > The latter works fine. The problem seems to happen with all diff\n>> > formats, so I think the issue is that git is not aggressive enough about\n>> > inserting the newline at the right spot when using separator mode.\n>>\n>> I guess that is one of the reasons why we made --format=%h a synonym\n>> to --pretty=tformat:%h and not --pretty=format:%h ;-)\n>\n> Yeah. I have never found \"--pretty=format\" to do what I want versus\n> tformat. I wish we could just get rid of it, but I think it is likely to\n> be used as a plumbing interface.\n>\n> So I think there probably _is_ a bug in it to be fixed, but my immediate\n> response is \"don't ever use --pretty=format:\".\n>\n> -Peff\n\nI have 1 issue with tformat in that I feel it reduces\nreadability a bit when using options. But I can use it if that\nis recommended over the other.\n\nWithout --name-status: This is OK.\n\n$ git log --graph --date=relative --decorate --abbrev-commit\n--format='%h - %aD (%ar)%d%n     %s - %an' -2\n* bf7ace7daf - Mon, 6 Feb 2017 13:09:32 -0800 (7 days ago) (HEAD ->\nrm/option-for-name-status)\n|      wip: --ns for --name-status - Rishikesh Mandvikar\n*   592e5c5bce - Wed, 1 Feb 2017 16:35:30 +0100 (12 days ago)\n(origin/master, origin/HEAD, master)\n|\\       Merge pull request #994 from\njeffhostetler/jeffhostetler/fscache_nfd - Johannes Schindelin\n\n\nWith --name-status: I'm sorry if I nitpick here but I think the\n--name-status items should either be preceeded and followed by\nblank line OR not (as in oneline) but not just preceded (example\nbelow).\n\n$ git log --graph --date=relative --decorate --abbrev-commit\n--format='%h - %aD (%ar)%d%n     %s - %an' -2 --name-status\n* bf7ace7daf - Mon, 6 Feb 2017 13:09:32 -0800 (7 days ago) (HEAD ->\nrm/option-for-name-status)\n|      wip: --ns for --name-status - Rishikesh Mandvikar\n|\n| M diff.c\n*   592e5c5bce - Wed, 1 Feb 2017 16:35:30 +0100 (12 days ago)\n(origin/master, origin/HEAD, master)\n|\\       Merge pull request #994 from\njeffhostetler/jeffhostetler/fscache_nfd - Johannes Schindelin\n\n\nSo either of below is better that above (I feel):\n\nBlank lines before and after --name-status items:\n\n$ git log --graph --date=relative --decorate --abbrev-commit\n--format='%h - %aD (%ar)%d%n     %s - %an' -2 --name-status\n* bf7ace7daf - Mon, 6 Feb 2017 13:09:32 -0800 (7 days ago) (HEAD ->\nrm/option-for-name-status)\n|      wip: --ns for --name-status - Rishikesh Mandvikar\n|\n| M diff.c\n|\n*   592e5c5bce - Wed, 1 Feb 2017 16:35:30 +0100 (12 days ago)\n(origin/master, origin/HEAD, master)\n|\\       Merge pull request #994 from\njeffhostetler/jeffhostetler/fscache_nfd - Johannes Schindelin\n\nNo blank lines before and after --name-status items:\n\n$ git log --graph --date=relative --decorate --abbrev-commit\n--format='%h - %aD (%ar)%d%n     %s - %an' -2 --name-status\n* bf7ace7daf - Mon, 6 Feb 2017 13:09:32 -0800 (7 days ago) (HEAD ->\nrm/option-for-name-status)\n|      wip: --ns for --name-status - Rishikesh Mandvikar\n| M diff.c\n*   592e5c5bce - Wed, 1 Feb 2017 16:35:30 +0100 (12 days ago)\n(origin/master, origin/HEAD, master)\n|\\       Merge pull request #994 from\njeffhostetler/jeffhostetler/fscache_nfd - Johannes Schindelin\n\nWhat do guys think?\n\nIf there is a way to get what I want using tformat?\n\n\nThanks,\nRM\n"},{"id":"311453","messageId":"20170213215107.7msmycclyslknpr2@sigill.intra.peff.net","threadId":"45124","inReplyTo":"CAM_JFCzniePuqJTFOy-odLfuKcBjssh0zk3PFBsVcm6Ww6iW5w@mail.gmail.com","subject":"Re: Incorrect pipe for git log graph when using --name-status option","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-13T21:51:07Z","receivedAt":"2017-02-13T21:51:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 13, 2017 at 01:43:45PM -0800, hIpPy wrote:\n\n> With --name-status: I'm sorry if I nitpick here but I think the\n> --name-status items should either be preceeded and followed by\n> blank line OR not (as in oneline) but not just preceded (example\n> below).\n\nYeah, I agree the output is a bit ugly.\n\nI don't think there is a way to do what you want currently. The\n--oneline code path has some internal magic that suppresses some of the\nnewlines.\n\nI think it is a good goal that anything that can be expressed via one of\nthe regular formats (like --oneline) can be expressed via custom\nformats. I don't know offhand how hard it would be to make this\nparticular case work. If somebody is interested in tackling this, they'd\nprobably need to dig around in pretty.c to see where the ONELINE code\npath diverge from the USER_FORMAT one, and then figure out how a user\ncan specify that they want the ONELINE-ish semantics for their format.\n\n-Peff\n"}]}