Bo Yang <struggleyb.nku@xxxxxxxxx> writes: > git log <revision> -L1,8 -L45,+6 <file1> -L/some/,/end/ -L9,29 <file2> <file3> > ... > Since '-L' option is also used by many other command, I don't know the > exact impact of this, anyway we can use another name anytime... > > 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. 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. -- 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