Re: cg-log "fatal: bad revision ''"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:

> 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

Yeah, I've been thinking about it but in the back of my head.

I think by hooking in found_guilty_entry(), you show the same
commit more than once when the commit is attributed to more than
one region.  This can probably be solved by remembering if the
current suspect commit matched, and show the log once if so.

And while you are remembering if the current <commit,file> pair
has some chunks attributed to it in that caller loop, I _think_
you would also want to remember which lines in the suspect
(i.e. <commit,file> pair) were blamed, and to which file in
which child commit (i.e. previous suspect).  Then after the
caller loop finds out that there are some lines that are
attributed to the current suspect, you can show the log, and
diff between the suspects' blobs, limited to the line ranges
that mattered. 

Currently that information is not recorded in blame_entry.  It
only has s_lno which indexes into the final image; the necessary
information is found in "struct patch", but after it is used to
split the blame entries and assign blame to the current suspect,
it is discarded.  For the purpose of this application you need
to record that as well.

While I do not think it is a rocket surgery, the change needed
to do this is not entirely trivial.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]