{"thread":{"id":"43347","subject":"git-blame: handling of revisions and filenames","startedAt":"2006-11-15T21:52:25Z","lastAt":"2006-11-29T18:29:07Z","messageCount":2,"participants":["Alex Riesen","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"294434","messageId":"20061115215225.GA4595@steel.home","threadId":"43347","inReplyTo":null,"subject":"git-blame: handling of revisions and filenames","fromName":"Alex Riesen","fromEmail":"fork0@t-online.de","sentAt":"2006-11-15T21:52:25Z","receivedAt":"2006-11-15T21:52:25Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"I noticed that there is no safe way to give a revision to git-blame:\nit can always be interpreted as an existing file:\n - \"git blame rev -- file.txt\" can fail if \"rev\" is a file\n - \"git blame rev^0 -- file.txt\" can file there is a \"rev^0\" file\n   (happens if you type too fast with a tool not designed for keyboard)\n - \"git blame file.txt rev\" is ambiguos too, for the same reasons.\n\nI did the simple patch (below) to resolve at least the very first one,\njust because that is how git-rev-list does it.\nBut if all forms of git-blame command line are expected to live, a\nmore serious surgery of the argv[] handling code needed.\nAnd I afraid the patch has a small chance of crashing: I don't check\nif there is enough space in argv (don't actually even know how to),\nso Junio, please do not apply it (it passes blame tests, though).\nI also suspect git-blame is not the only command using revision\nmachinery which has the same problem, so this message is more like a\ndiscussion starter.\n\ndiff --git a/builtin-blame.c b/builtin-blame.c\nindex 066dee7..83c8905 100644\n--- a/builtin-blame.c\n+++ b/builtin-blame.c\n@@ -1787,6 +1787,7 @@ int cmd_blame(int argc, const char **arg\n        /* Now we got rev and path.  We do not want the path pruning\n         * but we may want \"bottom\" processing.\n         */\n+       argv[unk++] = \"--\";\n        argv[unk] = NULL;\n \n        init_revisions(&revs, NULL);\n"},{"id":"298476","messageId":"7v8xhuqf7w.fsf@assigned-by-dhcp.cox.net","threadId":"43347","inReplyTo":"20061115215225.GA4595@steel.home","subject":"Re: git-blame: handling of revisions and filenames","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-29T18:29:07Z","receivedAt":"2006-11-29T18:29:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"fork0@t-online.de (Alex Riesen) writes:\n\n> And I afraid the patch has a small chance of crashing: I don't check\n> if there is enough space in argv (don't actually even know how to),\n\nActually this is a safe thing to do because we already know (and\nremoved) the \"path\" argument from the command line at that\npoint.  If the original command line did not have \"path\" we have\nalready rejected it.  So unk at that point never exceeds argc.\n\n> diff --git a/builtin-blame.c b/builtin-blame.c\n> index 066dee7..83c8905 100644\n> --- a/builtin-blame.c\n> +++ b/builtin-blame.c\n> @@ -1787,6 +1787,7 @@ int cmd_blame(int argc, const char **arg\n>         /* Now we got rev and path.  We do not want the path pruning\n>          * but we may want \"bottom\" processing.\n>          */\n> +       argv[unk++] = \"--\";\n>         argv[unk] = NULL;\n>  \n>         init_revisions(&revs, NULL);\n\nThanks.\n"}]}