Re: GSoC draft proposal: Line-level history browser

[Junio C Hamano <gitster@pobox.com>]

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

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.