{"thread":{"id":"7754","subject":"cg-log \"fatal: bad revision ''\"","startedAt":"2007-04-20T11:54:14Z","lastAt":"2007-04-23T22:05:30Z","messageCount":6,"participants":["MichaelTiloDressel@t-online.de","Petr Baudis","Michael Dressel","Linus Torvalds","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"39971","messageId":"1Hergt-0EBwVE0@fwd29.aul.t-online.de","threadId":"7754","inReplyTo":null,"subject":"cg-log \"fatal: bad revision ''\"","fromName":"MichaelTiloDressel@t-online.de","fromEmail":"michaeltilodressel@t-online.de","sentAt":"2007-04-20T11:54:14Z","receivedAt":"2007-04-20T11:54:14Z","isPatch":false,"sender":{"key":"michaeltilodressel@t-online.de","avatar":null},"body":"Hi,\n\nI moved a subdirectory in my working direcotry.\nIf I do cg-log on any of the files in the new subdirectory I get the\nerror:\n\n\nUse of uninitialized value in hash element at\n/usr/lib/cogito/cg-Xfollowrenames line 192, <$kid> line 12.\nfatal: bad revision ''\n\nI tried the moving of the subdirectory in two ways:\n1. using cg-mv\n2. git mv\nBut in both cases the result is the same.\n\nCheers,\nMichael\n"},{"id":"39982","messageId":"20070420135816.GO4489@pasky.or.cz","threadId":"7754","inReplyTo":"1Hergt-0EBwVE0@fwd29.aul.t-online.de","subject":"Re: cg-log \"fatal: bad revision ''\"","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-04-20T13:58:16Z","receivedAt":"2007-04-20T13:58:16Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nOn Fri, Apr 20, 2007 at 01:54:14PM CEST, MichaelTiloDressel@t-online.de wrote:\n> I moved a subdirectory in my working direcotry.\n> If I do cg-log on any of the files in the new subdirectory I get the\n> error:\n\n renames following in cg-log is known to be broken, please turn it off\nor use newer Cogito version which has it by default off.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"39994","messageId":"Pine.LNX.4.64.0704201900430.4275@castor.milkiway.cos","threadId":"7754","inReplyTo":"20070420135816.GO4489@pasky.or.cz","subject":"Re: cg-log \"fatal: bad revision ''\"","fromName":"Michael Dressel","fromEmail":"michaeltilodressel@t-online.de","sentAt":"2007-04-20T17:03:29Z","receivedAt":"2007-04-20T17:03:29Z","isPatch":false,"sender":{"key":"michaeltilodressel@t-online.de","avatar":null},"body":"On Fri, 20 Apr 2007, Petr Baudis wrote:\n\n> Hi,\n> \n> On Fri, Apr 20, 2007 at 01:54:14PM CEST, MichaelTiloDressel@t-online.de wrote:\n> > I moved a subdirectory in my working direcotry.\n> > If I do cg-log on any of the files in the new subdirectory I get the\n> > error:\n> \n> renames following in cg-log is known to be broken, please turn it off\n> or use newer Cogito version which has it by default off.\n\nThanx for the reply. Is there a way to follow renaming at all, either \nwith cogito or git?\n\nCheers,\nMichael\n\n> \n> -- \n> \t\t\t\tPetr \"Pasky\" Baudis\n> Stuff: http://pasky.or.cz/\n> Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.\n> \t\t-- Samuel Beckett\n> \n"},{"id":"40014","messageId":"alpine.LFD.0.98.0704201554550.9964@woody.linux-foundation.org","threadId":"7754","inReplyTo":"Pine.LNX.4.64.0704201900430.4275@castor.milkiway.cos","subject":"Re: cg-log \"fatal: bad revision ''\"","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-20T23:25:50Z","receivedAt":"2007-04-20T23:25:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Apr 2007, Michael Dressel wrote:\n> \n> Thanx for the reply. Is there a way to follow renaming at all, either \n> with cogito or git?\n\n\"git blame\" will follow renames, but doesn't really show things as a log, \nmore just as a \"these commits mattered\" thing.\n\nYou can use something like this patch to then make it *look* like a \"log\" \nfunction.\n\nJunio - I really think that something along these lines is worth doing, \nbut I wonder what the right semantics are. This patch is stupid, and just \nkeeps the \"blame\" semantics, just showing it in a \"log format\". It does \nmean that when I do\n\n\tgit blame -C --log block/ll_rw_block.c\n\nit will show entries for the old drivers/block/ll_rw_blk.c location.\n\nHOWEVER, it's still broken, because when you do logging, you don't \nactually care about the diffs at all, so *any* difference from the \nprevious version should show up, even if the lines don't show up in the \nend result. So this doesn't really do what people actually *want* to do, \nit does somethign much more complicated ;)\n\n\t\tLinus\n\n---\n builtin-blame.c | 21 +++++++++++++++++----\n 1 files changed, 17 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin-blame.c b/builtin-blame.c\nindex 8919b02..ee98753 100644\n--- a/builtin-blame.c\n+++ b/builtin-blame.c\n@@ -16,6 +16,7 @@\n #include \"quote.h\"\n #include \"xdiff-interface.h\"\n #include \"cache-tree.h\"\n+#include \"log-tree.h\"\n \n static char blame_usage[] =\n \"git-blame [-c] [-l] [-t] [-f] [-n] [-p] [-L n,m] [-S ] [-M] [-C] [-C] [--contents ] [--incremental] [commit] [--] file\\n\"\n@@ -30,6 +31,7 @@ static char blame_usage[] =\n \" -L n,m Process only line range n,m, counting from 1\\n\"\n \" -M, -C Find line movements within and across files\\n\"\n \" --incremental Show blame entries as we find them, incrementally\\n\"\n+\" --log Show blame entries as a log\\n\"\n \" --contents file Use 's contents as the final image\\n\"\n \" -S revs-file Use revisions from revs-file instead of calling git-rev-list\\n\";\n \n@@ -42,6 +44,7 @@ static int show_root;\n static int blank_boundary;\n static int incremental;\n static int cmd_is_annotate;\n+static int log;\n \n #ifndef DEBUG\n #define DEBUG 0\n@@ -1370,11 +1373,15 @@ static void write_filename_info(const char *path)\n * The blame_entry is found to be guilty for the range. Mark it\n * as such, and show it in incremental output.\n */\n-static void found_guilty_entry(struct blame_entry *ent)\n+static void found_guilty_entry(struct rev_info *revs, struct blame_entry *ent)\n {\n \tif (ent->guilty)\n \t\treturn;\n \tent->guilty = 1;\n+\tif (log) {\n+\t\tlog_tree_commit(revs, ent->suspect->commit);\n+\t\treturn;\n+\t}\n \tif (incremental) {\n \t\tstruct origin *suspect = ent->suspect;\n \n@@ -1443,7 +1450,7 @@ static void assign_blame(struct scoreboard *sb, struct rev_info *revs, int opt)\n \t\t/* Take responsibility for the remaining entries */\n \t\tfor (ent = sb->ent; ent; ent = ent->next)\n \t\t\tif (same_suspect(ent->suspect, suspect))\n-\t\t\t\tfound_guilty_entry(ent);\n+\t\t\t\tfound_guilty_entry(revs, ent);\n \t\torigin_decref(suspect);\n \n \t\tif (DEBUG) /* sanity */\n@@ -2072,7 +2079,6 @@ int cmd_blame(int argc, const char **argv, const char *prefix)\n \tcmd_is_annotate = !strcmp(argv[0], \"annotate\");\n \n \tgit_config(git_blame_config);\n-\tsave_commit_buffer = 0;\n \n \topt = 0;\n \tseen_dashdash = 0;\n@@ -2123,6 +2129,8 @@ int cmd_blame(int argc, const char **argv, const char *prefix)\n \t\t}\n \t\telse if (!strcmp(\"--incremental\", arg))\n \t\t\tincremental = 1;\n+\t\telse if (!strcmp(\"--log\", arg))\n+\t\t\tlog = 1;\n \t\telse if (!strcmp(\"--score-debug\", arg))\n \t\t\toutput_option |= OUTPUT_SHOW_SCORE;\n \t\telse if (!strcmp(\"-f\", arg) ||\n@@ -2244,6 +2252,11 @@ int cmd_blame(int argc, const char **argv, const char *prefix)\n \n \tinit_revisions(&revs, NULL);\n \tsetup_revisions(unk, argv, &revs, NULL);\n+\trevs.abbrev = DEFAULT_ABBREV;\n+\trevs.commit_format = CMIT_FMT_DEFAULT;\n+\trevs.verbose_header = 1;\n+\trevs.always_show_header = 1;\n+\n \tmemset(&sb, 0, sizeof(sb));\n \n \t/*\n@@ -2335,7 +2348,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)\n \n \tassign_blame(&sb, &revs, opt);\n \n-\tif (incremental)\n+\tif (incremental || log)\n \t\treturn 0;\n \n \tcoalesce(&sb);\n"},{"id":"40015","messageId":"7vwt06wqv8.fsf@assigned-by-dhcp.cox.net","threadId":"7754","inReplyTo":"alpine.LFD.0.98.0704201554550.9964@woody.linux-foundation.org","subject":"Re: cg-log \"fatal: bad revision ''\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-20T23:47:07Z","receivedAt":"2007-04-20T23:47:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Fri, 20 Apr 2007, Michael Dressel wrote:\n>> \n>> Thanx for the reply. Is there a way to follow renaming at all, either \n>> with cogito or git?\n>\n> \"git blame\" will follow renames, but doesn't really show things as a log, \n> more just as a \"these commits mattered\" thing.\n>\n> You can use something like this patch to then make it *look* like a \"log\" \n> function.\n>\n> Junio - I really think that something along these lines is worth doing, \n> but I wonder what the right semantics are. This patch is stupid, and just \n> keeps the \"blame\" semantics, just showing it in a \"log format\". It does \n> mean that when I do\n>\n> \tgit blame -C --log block/ll_rw_block.c\n>\n> it will show entries for the old drivers/block/ll_rw_blk.c location.\n>\n> HOWEVER, it's still broken, because when you do logging, you don't \n> actually care about the diffs at all, so *any* difference from the \n> previous version should show up, even if the lines don't show up in the \n> end result. So this doesn't really do what people actually *want* to do, \n> it does somethign much more complicated ;)\n>\n> \t\tLinus\n\nYeah, I've been thinking about it but in the back of my head.\n\nI think by hooking in found_guilty_entry(), you show the same\ncommit more than once when the commit is attributed to more than\none region. This can probably be solved by remembering if the\ncurrent suspect commit matched, and show the log once if so.\n\nAnd while you are remembering if the current pair\nhas some chunks attributed to it in that caller loop, I _think_\nyou would also want to remember which lines in the suspect\n(i.e. pair) were blamed, and to which file in\nwhich child commit (i.e. previous suspect). Then after the\ncaller loop finds out that there are some lines that are\nattributed to the current suspect, you can show the log, and\ndiff between the suspects' blobs, limited to the line ranges\nthat mattered. \n\nCurrently that information is not recorded in blame_entry. It\nonly has s_lno which indexes into the final image; the necessary\ninformation is found in \"struct patch\", but after it is used to\nsplit the blame entries and assign blame to the current suspect,\nit is discarded. For the purpose of this application you need\nto record that as well.\n\nWhile I do not think it is a rocket surgery, the change needed\nto do this is not entirely trivial.\n"},{"id":"40246","messageId":"Pine.LNX.4.64.0704232357120.29477@castor.milkiway.cos","threadId":"7754","inReplyTo":"alpine.LFD.0.98.0704201554550.9964@woody.linux-foundation.org","subject":"Re: cg-log \"fatal: bad revision ''\"","fromName":"Michael Dressel","fromEmail":"michaeltilodressel@t-online.de","sentAt":"2007-04-23T22:05:30Z","receivedAt":"2007-04-23T22:05:30Z","isPatch":false,"sender":{"key":"michaeltilodressel@t-online.de","avatar":null},"body":"On Fri, 20 Apr 2007, Linus Torvalds wrote:\n> \n> \n> On Fri, 20 Apr 2007, Michael Dressel wrote:\n> > \n> > Thanx for the reply. Is there a way to follow renaming at all, either \n> > with cogito or git?\n> \n> \"git blame\" will follow renames, but doesn't really show things as a log, \n> more just as a \"these commits mattered\" thing.\n> \n> You can use something like this patch to then make it *look* like a \"log\" \n> function.\n> \n> Junio - I really think that something along these lines is worth doing, \n> but I wonder what the right semantics are. This patch is stupid, and just \n> keeps the \"blame\" semantics, just showing it in a \"log format\". It does \n> mean that when I do\n> \n> \tgit blame -C --log block/ll_rw_block.c\n> \n> it will show entries for the old drivers/block/ll_rw_blk.c location.\n> \n> HOWEVER, it's still broken, because when you do logging, you don't \n> actually care about the diffs at all, so *any* difference from the \n> previous version should show up, even if the lines don't show up in the \n> end result. So this doesn't really do what people actually *want* to do, \n> it does somethign much more complicated ;)\n> \n> \t\tLinus\n> \n> ---\n> builtin-blame.c | 21 +++++++++++++++++----\n> 1 files changed, 17 insertions(+), 4 deletions(-)\n> \n> diff --git a/builtin-blame.c b/builtin-blame.c\n> index 8919b02..ee98753 100644\n> --- a/builtin-blame.c\n> +++ b/builtin-blame.c\n> @@ -16,6 +16,7 @@\n> #include \"quote.h\"\n> #include \"xdiff-interface.h\"\n> #include \"cache-tree.h\"\n> +#include \"log-tree.h\"\n> \n> static char blame_usage[] =\n> \"git-blame [-c] [-l] [-t] [-f] [-n] [-p] [-L n,m] [-S ] [-M] [-C] [-C] [--contents ] [--incremental] [commit] [--] file\\n\"\n> @@ -30,6 +31,7 @@ static char blame_usage[] =\n> \" -L n,m Process only line range n,m, counting from 1\\n\"\n> \" -M, -C Find line movements within and across files\\n\"\n> \" --incremental Show blame entries as we find them, incrementally\\n\"\n> +\" --log Show blame entries as a log\\n\"\n> \" --contents file Use 's contents as the final image\\n\"\n> \" -S revs-file Use revisions from revs-file instead of calling git-rev-list\\n\";\n> \n> @@ -42,6 +44,7 @@ static int show_root;\n> static int blank_boundary;\n> static int incremental;\n> static int cmd_is_annotate;\n> +static int log;\n> \n> #ifndef DEBUG\n> #define DEBUG 0\n> @@ -1370,11 +1373,15 @@ static void write_filename_info(const char *path)\n> * The blame_entry is found to be guilty for the range. Mark it\n> * as such, and show it in incremental output.\n> */\n> -static void found_guilty_entry(struct blame_entry *ent)\n> +static void found_guilty_entry(struct rev_info *revs, struct blame_entry *ent)\n> {\n> \tif (ent->guilty)\n> \t\treturn;\n> \tent->guilty = 1;\n> +\tif (log) {\n> +\t\tlog_tree_commit(revs, ent->suspect->commit);\n> +\t\treturn;\n> +\t}\n> \tif (incremental) {\n> \t\tstruct origin *suspect = ent->suspect;\n> \n> @@ -1443,7 +1450,7 @@ static void assign_blame(struct scoreboard *sb, struct rev_info *revs, int opt)\n> \t\t/* Take responsibility for the remaining entries */\n> \t\tfor (ent = sb->ent; ent; ent = ent->next)\n> \t\t\tif (same_suspect(ent->suspect, suspect))\n> -\t\t\t\tfound_guilty_entry(ent);\n> +\t\t\t\tfound_guilty_entry(revs, ent);\n> \t\torigin_decref(suspect);\n> \n> \t\tif (DEBUG) /* sanity */\n> @@ -2072,7 +2079,6 @@ int cmd_blame(int argc, const char **argv, const char *prefix)\n> \tcmd_is_annotate = !strcmp(argv[0], \"annotate\");\n> \n> \tgit_config(git_blame_config);\n> -\tsave_commit_buffer = 0;\n> \n> \topt = 0;\n> \tseen_dashdash = 0;\n> @@ -2123,6 +2129,8 @@ int cmd_blame(int argc, const char **argv, const char *prefix)\n> \t\t}\n> \t\telse if (!strcmp(\"--incremental\", arg))\n> \t\t\tincremental = 1;\n> +\t\telse if (!strcmp(\"--log\", arg))\n> +\t\t\tlog = 1;\n> \t\telse if (!strcmp(\"--score-debug\", arg))\n> \t\t\toutput_option |= OUTPUT_SHOW_SCORE;\n> \t\telse if (!strcmp(\"-f\", arg) ||\n> @@ -2244,6 +2252,11 @@ int cmd_blame(int argc, const char **argv, const char *prefix)\n> \n> \tinit_revisions(&revs, NULL);\n> \tsetup_revisions(unk, argv, &revs, NULL);\n> +\trevs.abbrev = DEFAULT_ABBREV;\n> +\trevs.commit_format = CMIT_FMT_DEFAULT;\n> +\trevs.verbose_header = 1;\n> +\trevs.always_show_header = 1;\n> +\n> \tmemset(&sb, 0, sizeof(sb));\n> \n> \t/*\n> @@ -2335,7 +2348,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)\n> \n> \tassign_blame(&sb, &revs, opt);\n> \n> -\tif (incremental)\n> +\tif (incremental || log)\n> \t\treturn 0;\n> \n> \tcoalesce(&sb);\n> \n\nThanx for your help.\n\nI have a version 1.5.2.rc0.2.g8ec0-dirty now with your changes patched in. \n\nThe command git blame -C --log myfile produces some alternative \ninformation to git log. \nI thought it would be a \"simple\" bug in cg-Xfollowrenames. As I learned \nfrom the follow-up postings it's more involved.\n\nCheers,\nMichael\n"}]}