Bo Yang <struggleyb.nku@xxxxxxxxx> writes: > The 'blame' way is very good if we only support one line range. But if > we want to support multiple line ranges, I don't think it is suitable > for that case. Anyway, how can I specify multi-ranges which refers to > multiple files at multiple revision and multiple line ranges using > above syntax? I would sort of see you may want to be able to say "explain lines 10 thru 15 of config.h and lines 100-115 of hello.c that appear in v1.2.0", but I think it is a total nonsense to ask for "ll 10-15 of config.h in v1.2.0 and ll 110-115 of hello.c in v1.0.0". After all they never existed in the same revision (otherwise you would have said "ll 7-13 of config.h and ll 110-115 of hello.c that appear in v1.0.0"). So I would reject the SVN-like "rev@" in the first place. While I don't seriously buy "multiple files" either, if that is really needed, I could be pursuaded with "log -- path1:10-15 path2:1-7", or "log -L path1:10-15 -Lpath2:1-7 -- path1 path2" or something similarly ugly like these, but that is not how we generally name things, and it probably shouldn't be a new option to "log" anymore. On the other hand, multiple ranges in a single file is something that may be quite reasonable, e.g. $ git log -L10-15 -L200-210 -- Makefile $ git log -L'*/^#ifdef WINDOWS/,/^#endif \/\* WINDOWS \/\*/' -- config.h As I already said, I wouldn't be so worried about multiple-range feature, but I would be worried about the usefulness of this feature, even for the case to track a single range of a single file, starting from one given revision. 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. So implementing "git log -L1,10 -- Makefile" might be just the matter of doing something like: 1. Run "git blame -L1,10 -- Makefile"; 2. Note the commits that appear in the output; 3. Topologically sort these commits; 4. Run "git show <the result of that toposort>" which is not very satisfying. And "git log -L1 -- Makefile" naturally degenerates into: 1. Run "git blame -L1,1 -- Makefile"; 2. Note the commits that appear in the output; 3. Run "git show <that commit>" which is not just unsatisfying, but is almost boring. I dunno. -- 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