Hi, On Mon, May 10, 2010 at 2:20 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> If there is no opposition for this kind of option syntax, I will try >> to implement it in revision.c. ;-) > > I'd rather not to see this in revision.c at all. The revision.c parser > has always been options and then pathspecs and never takes individual > filnames, except for "--follow" that is an afterthought checkbox hack that > lets the main parser parse and then reject a generic pathspec after the > fact. Ok, this will be put in the builtin/log.c > I think the right place to do this sort of thing is in the incremental > output of "blame". The command only takes individual filenames and never > takes general pathspecs, it knows about -L as line-range (and as far as I > see, it is the only command that does so) and I think its output routine > already has the right infrastructure for doing this. The "--incremental" > output itself is designed for porcelain scripts to interpret and do the UI > around it, but that does not mean it can have another mode that gives > human readable output. When "blame --incremental" emits the record that > says "these lines are blamed to this path in this commit", it has already > run internally necessary "diff" between blobs to find that > information---you should be able to re-run the diff (or keep the output > from "diff" around, but I would suggest against it) and show something > like "git log -p" output but is limited to the hunks that actually touch > the areas that we are following. > Hmm, maybe I should say something about my general plan about how to implement the line level browser here. Generally, I plan to change two place in major to make the history of line ranges. 1. The definition of TREESAME. TREESAME will be changed to consider the line ranges if -L option is given; With this, the history simplification can be done very well for line level history traversal. And even well for parent rewriting to support --graph option. Also, line tracing will be done along the process of the history simplification in the same time. And the tracing algorithm will be written in another new source file and get called in revision.c (maybe file_change and file_add_remove)... 2. The diff format, maybe a DIFF_FORMAT_LINE option will be added, and a new function builtin_diffline() will be added to output the line level diffs. This has some difference with my original proposal on the source files which need to modify. But I think this is the right way to do things after I have digged more into git source code. I hope this very rough idea can help you to understand what my following patches will look like. Regards! Bo -- My blog: http://blog.morebits.org -- 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