On Mon, Mar 22, 2010 at 3:41 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Bo Yang <struggleyb.nku@xxxxxxxxx> writes: > >>> When you want to know where the first few lines of Makefile >>> came from, and if blame says the first line came from 2731d048, that >>> really means that between the revision you started digging from and the >>> found revision, there is no commit that touched that particular line, but >>> equally importantly, that before that found revision, there wasn't a >>> corresponding line in that file---blame stopped exactly because there is >>> nobody before that found revision that the line can be blamed on. >> ... >> Yes, this is not satisfying. But as I understand, the line level >> history browser will do more than just this. It will not stop on 'step >> 4', it can follow the change history recursively and deeply, to find >> more. > > I am actually questioning the existence of "recursively and deeply to find > more"; the reason blame stopped at a particular commit is exactly because > there is no more---otherwise it wouldn't have stopped there but kept > digging deeper. I think an example may explain me well. commit 1 of the file: line 1 rev 1 line 2 rev 1 commit 2 of the file: line 1 rev 2 line 2 rev 2 commit 3 of the file: line 1 rev 3 line 2 rev 3 If we run, git blame file, it will show two lines are blamed on commit 3. Line level utility will also show rev2 and rev1 to users as the format like what git log provide. I think git blame focus on who produce the current code range. And the line level browser will provide more than that, it also answer, how the lines evolved into current condition. I hope I explain everything clearly. :) Regards! Bo -- 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