Re: Git: new feature suggestion

From: Jakub Narębski <jnareb@gmail.com>
Date: Jan 19, 2017, 21:48 UTC
Message-ID: <b96b71b9-f8a2-d039-6e8a-c64e7aac02a0@gmail.com>
In-Reply-To: <CA+55aFxAe8bH2xXkx1p5gYN+nc-D-vjNnfUeA_64Q3ttpbHq+w@mail.gmail.com>

W dniu 19.01.2017 o 19:39, Linus Torvalds pisze:

Show 16 quoted lines

> On Wed, Jan 18, 2017 at 10:33 PM, Konstantin Khomoutov
> <kostix+git@007spb.ru> wrote:
>>
>> Still, I welcome you to read the sort-of "reference" post by Linus
>> Torvalds [1] in which he explains the reasoning behind this approach
>> implemented in Git.
> 
> It's worth noting that that discussion was from some _very_ early days
> in git (one week into the whole thing), when none of those
> visualization tools were actually implemented.
> 
> Even now, ten years after the fact, plain git doesn't actually do what
> I outlined. Yes, "git blame -Cw" works fairly well, and is in general
> better than the traditional per-file "annotate". And yes, "git log
> --follow" does another (small) part of the outlined thing, but is
> really not very powerful.

It is really a pity that "git log --follow" is so limited; it's development stopped at early 'good enough' implementation.

For example "git log --follow gitweb/gitweb.perl" would not show the whole history of a file (which was once independent project), and "git log --follow" doesn't work for directories or multiple files.

Show 10 quoted lines

> 
> Some tools on top of git do more, but I think in general this is an
> area that could easily be improved upon. For example, the whole
> iterative and interactive drilling down in history of a particular
> file is very inconvenient to do with "git blame" (you find a commit
> that change the area in some way that you don't find interesting, so
> then you have to restart git blame with the parent of that
> unintersting commit).
> 
> You can do it in tig, but I suspect a more graphical tool might be better.

Well, we do have "git gui blame".

[...]

-- 
Jakub Narębski