Hi Linus, Às 6:39 PM de 1/19/2017, Linus Torvalds escreveu: > On Wed, Jan 18, 2017 at 10:33 PM, Konstantin Khomoutov > <kostix+git@xxxxxxxxx> 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. > > 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. > > .. and we still end up having a lot of things where we simply just > work with pathnames. For example, when doing merges, it' absolutely > _wonderful_ doing > > gitk --merge <filename> > > to see what happened to that filename that has a conflict during the > merge. But it's all based on the whole-file changes, and sometimes > you'd like to see just the commits that generate one particular > conflict (in the kernel, things like the MAINTAINERS file can have > quite a lot of changes, but they are all pretty idnependent, and what > you want to see is just "changes to this area"). > > We do have the "-L" flag to git log, but it doesn't actually work for > this particular case because of limitations. > > So what I'm trying to say is that the argument from 10+ years ago that > "you can do better with intelligent tools after-the-fact" is very much > true, but it's also true that we don't actually have all those > intelligent tools, and this is an area that could still be improved > upon. Some of them are actually available as add-ons in various > graphical IDE's that use git. > > Linus > I am currently facing some challenges in one of Linux subsystems where a rename of a set of folders and files would be the perfect scenario for future development, but the suggestion is not accepted, not because it's not correct, but because it makes the maintainer life harder in backporting bug fixes and new features to older kernel versions and because it is not easy to follow the renamed file/folder history from the kernel.org history logs. Like nature shows us, the ability to adapt is the key for survival, so Linux would gain a lot with some new features in git that can make maintainers life easier. Assisted-backporting would be an excellent feature for them. Did you ever thought about optimization backport operations through git or by an add-on to it? I am available to help if this feature makes sense for git users. Thanks, Joao
