cg-log "fatal: bad revision ''"

>   Hi,
> 
> On Fri, Apr 20, 2007 at 01:54:14PM CEST, MichaelTiloDressel@t-online.de wrote:
> > I moved a subdirectory in my working direcotry.
> > If I do cg-log on any of the files in the new subdirectory I get the
> > error:
> 
>   renames following in cg-log is known to be broken, please turn it off
> or use newer Cogito version which has it by default off.

> 
> -- 
> 				Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
> 		-- Samuel Beckett
> 

> On Fri, 20 Apr 2007, Michael Dressel wrote:
>> 
>> Thanx for the reply. Is there a way to follow renaming at all, either 
>> with cogito or git?
>
> "git blame" will follow renames, but doesn't really show things as a log, 
> more just as a "these commits mattered" thing.
>
> You can use something like this patch to then make it *look* like a "log" 
> function.
>
> Junio - I really think that something along these lines is worth doing, 
> but I wonder what the right semantics are. This patch is stupid, and just 
> keeps the "blame" semantics, just showing it in a "log format". It does 
> mean that when I do
>
> 	git blame -C --log block/ll_rw_block.c
>
> it will show entries for the old drivers/block/ll_rw_blk.c location.
>
> HOWEVER, it's still broken, because when you do logging, you don't 
> actually care about the diffs at all, so *any* difference from the 
> previous version should show up, even if the lines don't show up in the 
> end result. So this doesn't really do what people actually *want* to do, 
> it does somethign much more complicated ;)
>
> 		Linus

> 
> 
> On Fri, 20 Apr 2007, Michael Dressel wrote:
> > 
> > Thanx for the reply. Is there a way to follow renaming at all, either 
> > with cogito or git?
> 
> "git blame" will follow renames, but doesn't really show things as a log, 
> more just as a "these commits mattered" thing.
> 
> You can use something like this patch to then make it *look* like a "log" 
> function.
> 
> Junio - I really think that something along these lines is worth doing, 
> but I wonder what the right semantics are. This patch is stupid, and just 
> keeps the "blame" semantics, just showing it in a "log format". It does 
> mean that when I do
> 
> 	git blame -C --log block/ll_rw_block.c
> 
> it will show entries for the old drivers/block/ll_rw_blk.c location.
> 
> HOWEVER, it's still broken, because when you do logging, you don't 
> actually care about the diffs at all, so *any* difference from the 
> previous version should show up, even if the lines don't show up in the 
> end result. So this doesn't really do what people actually *want* to do, 
> it does somethign much more complicated ;)
> 
> 		Linus
> 
> ---
>  builtin-blame.c |   21 +++++++++++++++++----
>  1 files changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/builtin-blame.c b/builtin-blame.c
> index 8919b02..ee98753 100644
> --- a/builtin-blame.c
> +++ b/builtin-blame.c
> @@ -16,6 +16,7 @@
>  #include "quote.h"
>  #include "xdiff-interface.h"
>  #include "cache-tree.h"
> +#include "log-tree.h"
>  
>  static char blame_usage[] =
>  "git-blame [-c] [-l] [-t] [-f] [-n] [-p] [-L n,m] [-S <revs-file>] [-M] [-C] [-C] [--contents <filename>] [--incremental] [commit] [--] file\n"
> @@ -30,6 +31,7 @@ static char blame_usage[] =
>  "  -L n,m              Process only line range n,m, counting from 1\n"
>  "  -M, -C              Find line movements within and across files\n"
>  "  --incremental       Show blame entries as we find them, incrementally\n"
> +"  --log               Show blame entries as a log\n"
>  "  --contents file     Use <file>'s contents as the final image\n"
>  "  -S revs-file        Use revisions from revs-file instead of calling git-rev-list\n";
>  
> @@ -42,6 +44,7 @@ static int show_root;
>  static int blank_boundary;
>  static int incremental;
>  static int cmd_is_annotate;
> +static int log;
>  
>  #ifndef DEBUG
>  #define DEBUG 0
> @@ -1370,11 +1373,15 @@ static void write_filename_info(const char *path)
>   * The blame_entry is found to be guilty for the range.  Mark it
>   * as such, and show it in incremental output.
>   */
> -static void found_guilty_entry(struct blame_entry *ent)
> +static void found_guilty_entry(struct rev_info *revs, struct blame_entry *ent)
>  {
>  	if (ent->guilty)
>  		return;
>  	ent->guilty = 1;
> +	if (log) {
> +		log_tree_commit(revs, ent->suspect->commit);
> +		return;
> +	}
>  	if (incremental) {
>  		struct origin *suspect = ent->suspect;
>  
> @@ -1443,7 +1450,7 @@ static void assign_blame(struct scoreboard *sb, struct rev_info *revs, int opt)
>  		/* Take responsibility for the remaining entries */
>  		for (ent = sb->ent; ent; ent = ent->next)
>  			if (same_suspect(ent->suspect, suspect))
> -				found_guilty_entry(ent);
> +				found_guilty_entry(revs, ent);
>  		origin_decref(suspect);
>  
>  		if (DEBUG) /* sanity */
> @@ -2072,7 +2079,6 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
>  	cmd_is_annotate = !strcmp(argv[0], "annotate");
>  
>  	git_config(git_blame_config);
> -	save_commit_buffer = 0;
>  
>  	opt = 0;
>  	seen_dashdash = 0;
> @@ -2123,6 +2129,8 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
>  		}
>  		else if (!strcmp("--incremental", arg))
>  			incremental = 1;
> +		else if (!strcmp("--log", arg))
> +			log = 1;
>  		else if (!strcmp("--score-debug", arg))
>  			output_option |= OUTPUT_SHOW_SCORE;
>  		else if (!strcmp("-f", arg) ||
> @@ -2244,6 +2252,11 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
>  
>  	init_revisions(&revs, NULL);
>  	setup_revisions(unk, argv, &revs, NULL);
> +	revs.abbrev = DEFAULT_ABBREV;
> +	revs.commit_format = CMIT_FMT_DEFAULT;
> +	revs.verbose_header = 1;
> +	revs.always_show_header = 1;
> +
>  	memset(&sb, 0, sizeof(sb));
>  
>  	/*
> @@ -2335,7 +2348,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
>  
>  	assign_blame(&sb, &revs, opt);
>  
> -	if (incremental)
> +	if (incremental || log)
>  		return 0;
>  
>  	coalesce(&sb);
>