Re: GSoC draft proposal: Line-level history browser

[Bo Yang <struggleyb.nku@gmail.com>]

On Mon, Mar 22, 2010 at 1:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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

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