Re: GSoC draft proposal: Line-level history browser

> Bo Yang <struggleyb.nku@gmail.com> 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

>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.