On Mon, Mar 22, 2010 at 1:32 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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 Yeah, maybe one file multiple ranges is most rationale. > 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. I am sorry, but I did not catch up you here. You worried about the usefulness of the multi-range feature or the line level history browser? I think tracking a single range of a single file, starting from one given revision is useful when the line of history split on some point. This can let users focus on a single line of history using this feature. >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. 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 think this is useful when we focus just one a range of code and want to know how it become into such a now condition. Anyway, it is not a bad thing too add a new convenient feature to a daily tool. :) 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