{"thread":{"id":"40881","subject":"'git log --source' seems to fail to show ref name after the first tag comes out.","startedAt":"2015-11-25T10:29:02Z","lastAt":"2015-11-25T14:00:24Z","messageCount":3,"participants":["Raymundo","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"273720","messageId":"CAAe7MbAwWHXxVOu-CU7QpN0K3XTKJ1=xp4-dzSwBQatdAZ1vaQ@mail.gmail.com","threadId":"40881","inReplyTo":null,"subject":"'git log --source' seems to fail to show ref name after the first tag comes out.","fromName":"Raymundo","fromEmail":"gypark@gmail.com","sentAt":"2015-11-25T10:29:02Z","receivedAt":"2015-11-25T10:29:02Z","isPatch":false,"sender":{"key":"gypark@gmail.com","avatar":null},"body":"Hello,\n\nAt first, I'm sorry I'm not good at English.\n\n\nWhen I execute this command:\n\ngit log --oneline --source --all --decorate\n\nI get the output below: (I replaced commit messages written in Korean\nwith \"COMMIT MSG\")\n\n295c670 refs/heads/gyparkwiki_base (gyparkwiki_base) COMMIT MSG\nc130d61 refs/heads/master (HEAD -> master, origin/master, origin/HEAD)\nversion 2.27a\n6f6f40c refs/heads/gyparkwiki (gyparkwiki) COMMIT MSG\n...\na37772f refs/heads/gyparkwiki COMMIT MSG\nafeaa51 refs/heads/gyparkwiki COMMIT MSG\naf2676e  (tag: last_CVS_utf) COMMIT MSG   <- ref name is not shown\nfrom this line\nb4d27c9  COMMIT MSG\n4f834f8  COMMIT MSG\n...\n7534d49  COMMIT MSG\ne5c8a6c  *** empty log message ***\n596aa3e refs/tags/urlprefix (tag: urlprefix) COMMIT MSG  <- ref name\nappears again from this line\n8fc4de3 refs/tags/urlprefix COMMIT MSG\n...\na0b587 refs/tags/urlprefix COMMIT MSG\nf8526f9 refs/tags/urlprefix COMMIT MSG\n277478b  (tag: last_CVS_testwiki) COMMIT MSG <- ref name disappear\nagain from this line\n65919c8  *** empty log message ***\n...\n\nAs you can see, ref names in the second column repeats to disappear\nand come back, at every lines that contain tags.\n\nI tested using Git version 2.6.3\n\nFor reference, Git version 1.7.9.rc0 does not have this problem. It\nshows ref names on all lines well.\n\n\nMaybe is this a bug?\n\nThank you.\nG.Y.Park from South Korea\n"},{"id":"273733","messageId":"20151125125956.GC4504@sigill.intra.peff.net","threadId":"40881","inReplyTo":"CAAe7MbAwWHXxVOu-CU7QpN0K3XTKJ1=xp4-dzSwBQatdAZ1vaQ@mail.gmail.com","subject":"Re: 'git log --source' seems to fail to show ref name after the first tag comes out.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-11-25T12:59:57Z","receivedAt":"2015-11-25T12:59:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 25, 2015 at 07:29:02PM +0900, Raymundo wrote:\n\n> At first, I'm sorry I'm not good at English.\n\nNo problem. Your report was very clear. :)\n\n> When I execute this command:\n> \n> git log --oneline --source --all --decorate\n> [...]\n> As you can see, ref names in the second column repeats to disappear\n> and come back, at every lines that contain tags.\n\nI was able to reproduce this pretty easily with a short test case:\n\n  git init\n  git commit --allow-empty -m one\n  git commit --allow-empty -m two\n  git commit --allow-empty -m three\n  git tag -m mytag HEAD^\n\nStarting from one source works:\n\n  $ git log --oneline --source master\n  de009a4 master three\n  b75220d master two\n  62f49bd master one\n\nBut starting from the tag as well does not:\n\n  $ git log --oneline --source master mytag\n  de009a4 master three\n  b75220d  two\n  62f49bd  one\n\nOr more simply, starting from the tag never has any sources:\n\n  $ git log --oneline --source mytag\n  b75220d  two\n  62f49bd  one\n\nIt's like the tag paints its commit with an empty \"source\" field (and\nthen we propagate that down the graph).\n\n> I tested using Git version 2.6.3\n> \n> For reference, Git version 1.7.9.rc0 does not have this problem. It\n> shows ref names on all lines well.\n\nSounds like a good opportunity to use git-bisect. I came up with 2073949\n(traverse_commit_list: support pending blobs/trees with paths,\n2014-10-15) from git v2.2.0, which unfortunately was written by me. :)\n\nThis one-liner seems to fix it:\n\ndiff --git a/revision.c b/revision.c\nindex af2a18e..d434b8b 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -297,7 +297,6 @@ static struct commit *handle_commit(struct rev_info *revs,\n \t\t * through to the non-tag handlers below. Do not\n \t\t * propagate data from the tag's pending entry.\n \t\t */\n-\t\tname = \"\";\n \t\tpath = NULL;\n \t\tmode = 0;\n \t}\n\nBut I'm not sure if it causes other problems. In particular, I see why\nwe would not propagate a path field, but I do not know why the original\nwas avoiding propagating the name field.\n\n-Peff\n"},{"id":"273735","messageId":"CAAe7MbDu-Z7585A6tDcFg78pRrnDjvmdZV7oqGkqO8XchZUzaA@mail.gmail.com","threadId":"40881","inReplyTo":"20151125125956.GC4504@sigill.intra.peff.net","subject":"Re: 'git log --source' seems to fail to show ref name after the first tag comes out.","fromName":"Raymundo","fromEmail":"gypark@gmail.com","sentAt":"2015-11-25T14:00:24Z","receivedAt":"2015-11-25T14:00:24Z","isPatch":false,"sender":{"key":"gypark@gmail.com","avatar":null},"body":"2015-11-25 21:59 GMT+09:00 Jeff King <peff@peff.net>:\n>\n> Sounds like a good opportunity to use git-bisect. I came up with 2073949\n> (traverse_commit_list: support pending blobs/trees with paths,\n> 2014-10-15) from git v2.2.0, which unfortunately was written by me. :)\n>\n> This one-liner seems to fix it:\n>\n> diff --git a/revision.c b/revision.c\n> index af2a18e..d434b8b 100644\n> --- a/revision.c\n> +++ b/revision.c\n> @@ -297,7 +297,6 @@ static struct commit *handle_commit(struct rev_info *revs,\n>                  * through to the non-tag handlers below. Do not\n>                  * propagate data from the tag's pending entry.\n>                  */\n> -               name = \"\";\n>                 path = NULL;\n>                 mode = 0;\n>         }\n>\n> But I'm not sure if it causes other problems. In particular, I see why\n> we would not propagate a path field, but I do not know why the original\n> was avoiding propagating the name field.\n>\n> -Peff\n\nIt's a good news that you found the reason so soon.\n\nI'd like to wait for next version :-)\n\nThank you!\n"}]}