{"thread":{"id":"33550","subject":"Some observations on log -L","startedAt":"2013-04-20T09:56:09Z","lastAt":"2013-04-20T15:24:59Z","messageCount":2,"participants":["Ramkumar Ramachandra","Thomas Rast"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"214907","messageId":"CALkWK0k+LYro8jpmfRPmX8Wsj6aEWzyq3DYa6waDMsh5B=X7Tg@mail.gmail.com","threadId":"33550","inReplyTo":null,"subject":"Some observations on log -L","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-20T09:56:09Z","receivedAt":"2013-04-20T09:56:09Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nEver since 'git log -L' made it to `pu`, I've been playing with it to\nsee how it can be useful.  Here are some of my observations:\n\n1. Specifying line ranges by hand are too painful.  I would really\nlove it if it could parse the lines off a patch prepared by\nformat-patch or something.\n\n2. Specifying regex ranges are really useful to see the history of a\nfunction.  But I think it could really benefit from a tool that\nactually understands the language (using Clang Tooling).  If we were\nto build such a tool, git-core could benefit immensely from it: we'd\nhave smarter merges too, for instance.\n\n3. Often, I want to know the people to contact for a segment of code.\nBlame is useless here, because it only considers the most recent\ncommit, when I want to know the authors of all the commits that helped\nshaped that segment of code.  So, I think shortlog could really\nbenefit from a -L.  Is this easily doable?\n\nThanks for listening.\n"},{"id":"214936","messageId":"87bo99usvo.fsf@hexa.v.cablecom.net","threadId":"33550","inReplyTo":"CALkWK0k+LYro8jpmfRPmX8Wsj6aEWzyq3DYa6waDMsh5B=X7Tg@mail.gmail.com","subject":"Re: Some observations on log -L","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-04-20T15:24:59Z","receivedAt":"2013-04-20T15:24:59Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Ever since 'git log -L' made it to `pu`, I've been playing with it to\n> see how it can be useful.  Here are some of my observations:\n>\n> 1. Specifying line ranges by hand are too painful.  I would really\n> love it if it could parse the lines off a patch prepared by\n> format-patch or something.\n\nTrue, but I'm not sure that starting from a patch is the right thing.\nAt least in my case, when I have a patch ready, I longer need to\ninvestigate anything ;-)\n\nPerhaps a \"line-log all the ranges touched by this commit\" would be more\nuseful.\n\nYou can achieve both with some hack like\n\n  eval git log 1640632 $(git show 1640632 | perl -ne '\n    $h=1 if /^diff /;\n    $f=$1 if $h and m{\\+\\+\\+ ./(.*)$};\n    if (/@@ .* \\+(\\d+)(?:,(\\d+))/) {\n      print \" -L$1,+$2:$f\"; $h=0;\n    };\n  ')\n\nNote that you need to specify the commit in two places.  I think I'll\nactually make that a script and try it to see if it's worth\nimplementing.  Quoting of the -L args is of course an exercise left to\nthe reader ;-)\n\n> 2. Specifying regex ranges are really useful to see the history of a\n> function.  But I think it could really benefit from a tool that\n> actually understands the language (using Clang Tooling).  If we were\n> to build such a tool, git-core could benefit immensely from it: we'd\n> have smarter merges too, for instance.\n\nIs there any research on this?\n\nI imagine you would use whatever parser you have at hand to process the\ninput into a syntax tree, then run diff over those trees.  There should\nbe some research on how to get meaningful diffs of them?  And then you\nsomehow have to turn the tree-diff into a human-readable output.\n\nIn any case you could start by prototyping such a diff algorithm on a\nfile basis; people could then start using it as an external diff driver.\n\n> 3. Often, I want to know the people to contact for a segment of code.\n> Blame is useless here, because it only considers the most recent\n> commit, when I want to know the authors of all the commits that helped\n> shaped that segment of code.  So, I think shortlog could really\n> benefit from a -L.  Is this easily doable?\n\nNot really.  You're touching on a sore point of the current\nimplementation, which is that it's not properly tied into the log and\ndiff infrastructures.  I figured that would block it for too long, so I\ngave up on trying to do that for the first version.\n\nSo it just runs captures the history that log walks, does a separate\nprocessing step and handcrafts a diff in its own output machinery, which\nisn't very nice for many reasons, including that we can't run any other\ndiff- or log-like stuff on top of log -L output.\n\nThat precludes many uses, like shortlog you mentioned, or color-words.\nI think Junio and me hashed out some ideas for how it *should* be tied\ntogether in some earlier thread.  The gist of it is that there are\nreally three separate things going on here:\n\n* Pathspec-like filtering with proper -M support.  This should be\n  unified with --follow.  That's actually the next thing I want to try,\n  because it should give a properly implemented --follow along the way.\n\n* A pass of commit filtering based on intersecting the ranges we're\n  interested in with the diffs of commits, and mapping them \"across\".\n  This should be hooked as a cleanly separated step into the log\n  machinery.\n\n* Diff output filtering based on the ranges that we found.  This should\n  be done as a filter somewhere in the diff machinery, preferably before\n  word-diff.\n\n(The first step is actually a performance optimization, but it would not\nbe a practical algorithm without it.)\n\nThanks for the input.  Let me know if you manage to break it somehow :-)\n\n\nAnd for a bit of shameless pluggery (you probably saw it on IRC already,\nbut mainly for other curious readers):\n\n  git://github.com/trast/git.git tr/gitk-line-log\n\nhas a version of gitk that supports -L.  I hacked it up yesterday, and\nwhile it seems to work, I want to play with it a little until I'm\nsatisfied that I didn't break gitk for other uses.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"}]}