{"thread":{"id":"24807","subject":"Wrap up of Line Level History Browser","startedAt":"2010-08-20T13:51:20Z","lastAt":"2010-08-22T20:57:06Z","messageCount":3,"participants":["Bo Yang","Thomas Rast","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"148567","messageId":"AANLkTikORUbVA+AJNT-Z1d+KJ-j1xxRdBN4hzLuXBXX5@mail.gmail.com","threadId":"24807","inReplyTo":null,"subject":"Wrap up of Line Level History Browser","fromName":"Bo Yang","fromEmail":"struggleyb.nku@gmail.com","sentAt":"2010-08-20T13:51:20Z","receivedAt":"2010-08-20T13:51:20Z","isPatch":false,"sender":{"key":"struggleyb.nku@gmail.com","avatar":"https://avatars.githubusercontent.com/u/233030?v=4"},"body":"Hi,\n\nToday is the last day of GSoC, here is a wrap up of the whole work of\nthis summer from Line Level History Browser.\n\nGenerally, the goal of this project is to:\n1. 'git log -L' to trace multiple ranges from multiple files;\n2. move/copy detect when we reach the end of some lines(where lines\nare added from scratch).\n\nAnd now, we have supports in detail:\n1. 'git log -L' can trace multiple ranges from multiple files;\n2. we support the same syntax with 'git blame' '-L' options;\n3. we integrate the 'git log -L' with '--graph' options with\nparent-rewriting to make the history looks better and clear;\n4. move/copy detect is in its half way. We get a nearly workable\nversion of it, and now it is in a phrase of refactor, so in the scope\nof GSoC, move/copy detect only partly complete.\n\nNow, the first series of patches of core 'git log -L' functionality is\ncooked in 'pu' and the move/code detect code is in a refactor. That's\nthe general status of my project.\n\nIn the following days, some more work will be put into the refactor\nand I hope I can make the re-written version appear in next week. :)\n\nFinally, many thanks to my mentor Thomas, he helped me on designing\nhow to implement things and was very patient to point out the flaw of\nvarious version of 'git log -L' and this make me improve my code\ncontinuously. And thanks to Jens, Junio to provide so many valuable\ncomments. Thanks a lot!\n\n-- \nRegards!\nBo\n----------------------------\nMy blog: http://blog.morebits.org\nWhy Git: http://www.whygitisbetterthanx.com/\n"},{"id":"148716","messageId":"201008222247.45600.trast@student.ethz.ch","threadId":"24807","inReplyTo":"AANLkTikORUbVA+AJNT-Z1d+KJ-j1xxRdBN4hzLuXBXX5@mail.gmail.com","subject":"Re: Wrap up of Line Level History Browser [long]","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2010-08-22T20:47:45Z","receivedAt":"2010-08-22T20:47:45Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Hi Bo, *\n\nAs a brief introduction to people who haven't been following, and\npartially answering an earlier question in another thread:\n\nDavid Lang wrote:\n> what is this series?\n> \n> this is all good incramental information, but there's no info indicating \n> what this is updating.\n\nFor me it replaces a manual iterative process to find out in what ways\na function was patched until it came to have its current shape:\n\n  git-blame the area, find the most recent commit C\n  while 1:\n    git show C\n    if that explains the code: break\n    git-blame the area in C^\n    find the most recent commit and call it C again\n\nI do this a lot when a particular section of code puzzles me or seems\nbuggy, to see if any commit message provides a reason for it.  I think\n(but I never got good with it) the \"blame parent\" feature of 'git gui\nblame' covers a similar use-case.\n\nAll of this can now be replaced by a simple\n\n  git log -L <range> <filename>\n\nA good example that I did a lot of testing with:\n\n  git log --graph be58e70d^ -L /builtin_funcname_pattern/,/^}/ diff.c\n\nTry it.  I can follow up with more examples if you're interested, but\nit's much more fun if you're actually looking for some explanations.\n\n\nAs for the project: First off, many thanks Bo for all the work you put\ninto it.  I think you planned and executed this project very well.\nThere were some minor changes to the original drafts, but comparing\nthe feature list from the project proposal (this is only an abstract,\nthe real list was much longer):\n\n} 1. Line-history (main work :-)\n} 2. -M/-C support\n} 3. Configurable context\n} 4. -C -C support\n} 5. Fuzzy matching for -M/-C\n} 6. Configurable display (--graph)\n} 7. Machine-readable output (--porcelain)\n} 8. Support git-log options where possible\n\nwith the feature list you posted\n\nBo Yang wrote:\n> And now, we have supports in detail:\n> 1. 'git log -L' can trace multiple ranges from multiple files;\n> 2. we support the same syntax with 'git blame' '-L' options;\n> 3. we integrate the 'git log -L' with '--graph' options with\n> parent-rewriting to make the history looks better and clear;\n> 4. move/copy detect is in its half way. We get a nearly workable\n> version of it, and now it is in a phrase of refactor, so in the scope\n> of GSoC, move/copy detect only partly complete.\n\nwe see that while there's still some work to be done in the -C -C\narea, most of the features are there.  The ones that didn't make it\nare 5 (fuzzy matching) and to some extent 3 (context control; there is\n--full-line-diff).  We agreed to drop 7 (--porcelain) in private\nconversation when we found out that gitk is already halfway ready to\nread --format=full output.  Combined-diff style output for merges was\nalso added to the list sometime in summer, then dropped again because\nof time constraints.\n\n\nNext, thanks also to Jens who co-mentored.  Things went very smooth\ndespite my roughly 4 weeks of absence during the GSoC months thanks to\nhis efforts.\n\n\nFinally, I'd like to outline some of my dreams^Wfuture directions for\nthis feature.  Some of them have been promised by Bo privately, but\nlet's not put any pressure on him now that the project is officially\nover.\n\n* Support in gitk to read --format=full output (within some\n  constraints maybe), thus letting us see the output more\n  conveniently.\n\n* Support in gitk to parse the -L option and pass it to the right\n  git-log invocation.\n\n* Combined-diff style output for merges.\n\n* As Junio has suggested in a thread about the option parsing, it\n  should be possible to extend this to scan history both ways, i.e.,\n  \"I have lines 11-19 in commit abcdef, explain how they came and\n  where they went\".\n\n\nI think that's all for today, thanks for reading so much text.\n\nRegards\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"148717","messageId":"AANLkTi=R54C8xQGnPW3VPFnyL+784nG8RMEcHF9s_THD@mail.gmail.com","threadId":"24807","inReplyTo":"201008222247.45600.trast@student.ethz.ch","subject":"Re: Wrap up of Line Level History Browser [long]","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-08-22T20:57:06Z","receivedAt":"2010-08-22T20:57:06Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Thomas Rast wrote:\n\n> For me it replaces a manual iterative process to find out in what ways\n> a function was patched until it came to have its current shape:\n>\n>  git-blame the area, find the most recent commit C\n>  while 1:\n>    git show C\n>    if that explains the code: break\n>    git-blame the area in C^\n>    find the most recent commit and call it C again\n[...]\n> All of this can now be replaced by a simple\n>\n>  git log -L <range> <filename>\n>\n> A good example that I did a lot of testing with:\n>\n>  git log --graph be58e70d^ -L /builtin_funcname_pattern/,/^}/ diff.c\n\nThanks. (And thanks to Bo for implementing it!)\n"}]}