{"thread":{"id":"26794","subject":"gsoc - Better git log --follow support","startedAt":"2011-03-19T19:24:20Z","lastAt":"2011-04-15T19:41:33Z","messageCount":12,"participants":["Michał Łowicki","Jakub Narebski","Jeff King","Junio C Hamano","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"163771","messageId":"AANLkTi=n7e70UqYU+6wpG4cu95fsg39tVM6=7fpfdZFz@mail.gmail.com","threadId":"26794","inReplyTo":null,"subject":"gsoc - Better git log --follow support","fromName":"Michał Łowicki","fromEmail":"mlowicki@gmail.com","sentAt":"2011-03-19T19:24:20Z","receivedAt":"2011-03-19T19:24:20Z","isPatch":false,"sender":{"key":"mlowicki@gmail.com","avatar":"https://gravatar.com/avatar/dd126ae0130dbe5194e2965c12ebfef67128acdd40408e38d212d508cd831e13?d=mp&s=160"},"body":"Hi!\n\nI'm looking at idea about better git log --follow support from\nhttps://git.wiki.kernel.org/index.php/SoC2011Ideas .There is something\nlike this - \"[.. ] it does not interact well with git's usual history\nsimplification [...]\". Can someone elaborate this? I've found History\nSimplification in git rev-list man but don't know yet about issues\nwith --follow.\n\n-- \nBR,\nMichał Łowicki\n"},{"id":"163784","messageId":"m339mi6ago.fsf@localhost.localdomain","threadId":"26794","inReplyTo":"AANLkTi=n7e70UqYU+6wpG4cu95fsg39tVM6=7fpfdZFz@mail.gmail.com","subject":"Re: GSoC - Better \"git log --follow\" support","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-03-19T21:57:02Z","receivedAt":"2011-03-19T21:57:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Michał Łowicki <mlowicki@gmail.com> writes:\n\n> I'm looking at idea about better git log --follow support from\n> https://git.wiki.kernel.org/index.php/SoC2011Ideas .There is something\n> like this - \"[.. ] it does not interact well with git's usual history\n> simplification [...]\". Can someone elaborate this? I've found History\n> Simplification in git rev-list man but don't know yet about issues\n> with --follow.\n\nWell, '--follow' option to git-log is a bit of bolted-on hack.  \n\nIt does work only for single file (it doesn't work e.g. for\ndirectory), and it not always work correctly.  For example\n\n  $ git log --follow gitweb/gitweb.perl\n\ncorrectly follows gitweb history across gitweb.cgi => gitweb.perl\nrename in 5d043a3 (gitweb: fill in gitweb configuration by Makefile,\n2006-08-01), but it doesn't follow through subtree merging of gitweb\nrepository in 0a8f4f0 (Merge git://git.kernel.org/pub/scm/git/gitweb,\n2006-06-10).\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"163901","messageId":"20110321122407.GH16334@sigill.intra.peff.net","threadId":"26794","inReplyTo":"AANLkTi=n7e70UqYU+6wpG4cu95fsg39tVM6=7fpfdZFz@mail.gmail.com","subject":"Re: gsoc - Better git log --follow support","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-21T12:24:07Z","receivedAt":"2011-03-21T12:24:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Mar 19, 2011 at 08:24:20PM +0100, Michał Łowicki wrote:\n\n> I'm looking at idea about better git log --follow support from\n> https://git.wiki.kernel.org/index.php/SoC2011Ideas .There is something\n> like this - \"[.. ] it does not interact well with git's usual history\n> simplification [...]\". Can someone elaborate this? I've found History\n> Simplification in git rev-list man but don't know yet about issues\n> with --follow.\n\nIn short, history simplification is a way of looking at a subset of the\ncommit history graph, but in a way that makes it look like a complete\ngraph. Imagine I have a linear history like this:\n\n  A--B--C\n\nwhere \"A\" modifies \"file1\", \"B\" modifies \"file2\", and \"C\" modifies\n\"file1\" again. If I ask for the history of \"file1\" with \"git log file1\",\nthen git will pretend as if the graph looks like:\n\n  A--C\n\nincluding rewriting the parent of \"C\" to point to \"A\" (because the\nparent pointer is basically an edge in the graph).\n\nIf you are just doing a straight \"git log\", the actual parentage is not\nthat interesting. We either show commits or we don't, and we don't show\nlinks between them. But try \"git log --graph\" or \"gitk\", which do care\nabout the edges. They want to show you a whole connected graph.\n\nNow consider --follow. It doesn't happen during the commit limiting\nphase, but instead it happens while we're showing commits. And if it\ndecides a commit isn't interesting, we don't show it. That works OK for\n\"git log\", but it makes the graph for other things disjointed.\n\nYou can see it in this example:\n\n  # make the A-B-C repo we mentioned above\n  git init repo && cd repo\n  echo content >file1 && git add file1 && git commit -m one\n  echo content >file2 && git add file2 && git commit -m two\n  echo content >>file1 && git add file1 && git commit -m three\n\n  # Now look at it in gitk; we see a nice linear graph.\n  gitk\n\n  # Now let's try it with path limiting. We see a nice subgraph that\n  # pretends to be linear, because we \"squished\" out the uninteresting\n  # nodes.\n  gitk file1\n\n  # Now let's make some more commits with a rename.\n  echo content >>file2 && git commit -a -m four\n  git mv file1 newfile && git commit -m five\n  echo content >>newfile && git commit -a -m six\n\n  # If we use path limiting, we'll only see the two most recent commits.\n  # We get stopped at the rename because path limiting is just about the\n  # pathname.\n  gitk newfile\n\n  # So we can use --follow to follow the rename. First let's try simple\n  # output. You should see commits 1, 3, 5, and 6, which touched either\n  # newfile or its rename source, file1. \n  git log --oneline --follow newfile\n\n  # But now look at it in gitk. Commit 4 is included as a boundary\n  # commit, but we fail to notice that it connects to three. And we\n  # don't see commit 3 connecting to anything, and commit 1 is missing\n  # entirely.\n  gitk --follow newfile\n\nObviously this a pretty simplistic example. But you can imagine in a\nhistory with a lot of branching how useful this simplification is to\nunderstanding what happened to a subset of the tree.\n\nJakub mentioned another example with gitweb's subtree merge not being\nfound by --follow. I haven't looked into that case, but it may be\nrelated (or it may simply be a defect in follow finding the right\nsource).\n\n-Peff\n"},{"id":"164099","messageId":"AANLkTi=woLeveur6gKnSXTRzmS8nB0o4M9HegJ+GNUCa@mail.gmail.com","threadId":"26794","inReplyTo":"20110321122407.GH16334@sigill.intra.peff.net","subject":"Re: gsoc - Better git log --follow support","fromName":"Michał Łowicki","fromEmail":"mlowicki@gmail.com","sentAt":"2011-03-22T23:23:45Z","receivedAt":"2011-03-22T23:23:45Z","isPatch":false,"sender":{"key":"mlowicki@gmail.com","avatar":"https://gravatar.com/avatar/dd126ae0130dbe5194e2965c12ebfef67128acdd40408e38d212d508cd831e13?d=mp&s=160"},"body":"W dniu 21 marca 2011 13:24 użytkownik Jeff King <peff@peff.net> napisał:\n> On Sat, Mar 19, 2011 at 08:24:20PM +0100, Michał Łowicki wrote:\n>\n>> I'm looking at idea about better git log --follow support from\n>> https://git.wiki.kernel.org/index.php/SoC2011Ideas .There is something\n>> like this - \"[.. ] it does not interact well with git's usual history\n>> simplification [...]\". Can someone elaborate this? I've found History\n>> Simplification in git rev-list man but don't know yet about issues\n>> with --follow.\n>\n> In short, history simplification is a way of looking at a subset of the\n> commit history graph, but in a way that makes it look like a complete\n> graph. Imagine I have a linear history like this:\n>\n>  A--B--C\n>\n> where \"A\" modifies \"file1\", \"B\" modifies \"file2\", and \"C\" modifies\n> \"file1\" again. If I ask for the history of \"file1\" with \"git log file1\",\n> then git will pretend as if the graph looks like:\n>\n>  A--C\n>\n> including rewriting the parent of \"C\" to point to \"A\" (because the\n> parent pointer is basically an edge in the graph).\n>\n> If you are just doing a straight \"git log\", the actual parentage is not\n> that interesting. We either show commits or we don't, and we don't show\n> links between them. But try \"git log --graph\" or \"gitk\", which do care\n> about the edges. They want to show you a whole connected graph.\n>\n> Now consider --follow. It doesn't happen during the commit limiting\n> phase, but instead it happens while we're showing commits. And if it\n> decides a commit isn't interesting, we don't show it. That works OK for\n> \"git log\", but it makes the graph for other things disjointed.\n>\n> You can see it in this example:\n>\n>  # make the A-B-C repo we mentioned above\n>  git init repo && cd repo\n>  echo content >file1 && git add file1 && git commit -m one\n>  echo content >file2 && git add file2 && git commit -m two\n>  echo content >>file1 && git add file1 && git commit -m three\n>\n>  # Now look at it in gitk; we see a nice linear graph.\n>  gitk\n>\n>  # Now let's try it with path limiting. We see a nice subgraph that\n>  # pretends to be linear, because we \"squished\" out the uninteresting\n>  # nodes.\n>  gitk file1\n>\n>  # Now let's make some more commits with a rename.\n>  echo content >>file2 && git commit -a -m four\n>  git mv file1 newfile && git commit -m five\n>  echo content >>newfile && git commit -a -m six\n>\n>  # If we use path limiting, we'll only see the two most recent commits.\n>  # We get stopped at the rename because path limiting is just about the\n>  # pathname.\n>  gitk newfile\n>\n>  # So we can use --follow to follow the rename. First let's try simple\n>  # output. You should see commits 1, 3, 5, and 6, which touched either\n>  # newfile or its rename source, file1.\n>  git log --oneline --follow newfile\n>\n>  # But now look at it in gitk. Commit 4 is included as a boundary\n>  # commit, but we fail to notice that it connects to three. And we\n>  # don't see commit 3 connecting to anything, and commit 1 is missing\n>  # entirely.\n>  gitk --follow newfile\n\nWhy commit 4 is displayed here (changes only file2) ?\n\n# git log with graph works here OK. It displays six -- five .. --\nthree .. - one .In this case results shouldn't be similar to gitk ?\ngit log --graph --follow newfile\n\n>\n> Obviously this a pretty simplistic example. But you can imagine in a\n> history with a lot of branching how useful this simplification is to\n> understanding what happened to a subset of the tree.\n>\n> Jakub mentioned another example with gitweb's subtree merge not being\n> found by --follow. I haven't looked into that case, but it may be\n> related (or it may simply be a defect in follow finding the right\n> source).\n>\n> -Peff\n>\n\n\n\n-- \nPozdrawiam,\nMichał Łowicki\n"},{"id":"164161","messageId":"20110323162023.GC30337@sigill.intra.peff.net","threadId":"26794","inReplyTo":"AANLkTi=woLeveur6gKnSXTRzmS8nB0o4M9HegJ+GNUCa@mail.gmail.com","subject":"Re: gsoc - Better git log --follow support","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-23T16:20:23Z","receivedAt":"2011-03-23T16:20:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 23, 2011 at 12:23:45AM +0100, Michał Łowicki wrote:\n\n> >  # But now look at it in gitk. Commit 4 is included as a boundary\n> >  # commit, but we fail to notice that it connects to three. And we\n> >  # don't see commit 3 connecting to anything, and commit 1 is missing\n> >  # entirely.\n> >  gitk --follow newfile\n> \n> Why commit 4 is displayed here (changes only file2) ?\n\nIt's part of how gitk shows the graph. It shows all of the commits you\nasked for with blue nodes, and then it shows the \"boundary\" commits with\na special white node. This lets you distinguish between actual root\ncommits (i.e., ones with no parents) and ones whose parents are simply\nuninteresting to the current query.\n\n> # git log with graph works here OK. It displays six -- five .. --\n> three .. - one .In this case results shouldn't be similar to gitk ?\n> git log --graph --follow newfile\n\nSort of. Notice the \"...\" in the output (it is easier to see with \"git\nlog --graph --oneline --follow newfile). It is not showing the\nsimplified history, but instead indicates that there were some commits\nomitted in between the two points. It doesn't make the output terrible\nin such a simple linear case. But consider a case with branching:\n\n  # Our A-B-C repo\n  git init repo && cd repo\n  echo content >file1 && git add file1 && git commit -m one\n  echo content >file2 && git add file2 && git commit -m two\n  echo content >>file1 && git add file1 && git commit -m three\n\n  # Now make a side branch that also touches file1\n  git checkout -b side HEAD^\n  echo content >>file1 && git commit -a -m four\n\n  # And merge them back to together\n  git merge master\n\n  # And then do our other commits with rename on top\n  echo content >>file2 && git commit -a -m five\n  git mv file1 newfile && git commit -m six\n  echo content >>newfile && git commit -a -m seven\n\nShowing \"git log --graph --oneline --follow newfile\" becomes a bit more\nconfusing. A simplified history would show \"six\" as the merge between\nthe two branches, but here it happens at some indeterminate point in the\nhistory that is not shown.\n\nAnd again, this is a simple example. For something more complex, try\nthis in git.git:\n\n  # We know builtin-add.c got renamed to builtin/add.c, so\n  # let's cheat and tell git which paths we're interested in.\n  # The resulting graph is pretty readable, and is more or less what we\n  # would want from --follow.\n  git log --oneline --graph -- builtin-add.c builtin/add.c\n\n  # Now try it with --follow. Not so pretty.\n  git log --oneline --graph --follow builtin/add.c\n\n-Peff\n"},{"id":"164165","messageId":"7v8vw5g4f0.fsf@alter.siamese.dyndns.org","threadId":"26794","inReplyTo":"20110323162023.GC30337@sigill.intra.peff.net","subject":"Re: gsoc - Better git log --follow support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-23T16:58:11Z","receivedAt":"2011-03-23T16:58:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n>   # Now try it with --follow. Not so pretty.\n>   git log --oneline --graph --follow builtin/add.c\n\nIs that an artifact of history simplification?\n\nI've always thought that it was because --follow hack used a single global\npathspec that flipped at a rename boundary,regardless of which part of the\nhistory (i.e. the branch that was before the rename or after the rename)\nit is following.  So if you have two branches merged together:\n\n        o---o---o---o---o---x---x---x\n       /                   / \n   ...o---o---o---x---x---x\n\nwhere commits marked with 'x' has it under the new path while commits\nmarked with 'o' has it under the old path, and start to dig the history\nfrom the rightmost commit, the hack notices the rename at the transition\nbetween the \"o---x\" on the upper branch and from then on keep digging the\nhistory using the old path as the pathspec.  The commit history traversal\ngoes reverse-chronologically, so when inspecting the next commit, which is\nthe rightmost commit on the lower branch, the hack fails because it uses a\nwrong pathspec (at that point it should still be using the new path as the\npathspec, but it already has switched to the old path).\n"},{"id":"164166","messageId":"20110323170655.GA4392@sigill.intra.peff.net","threadId":"26794","inReplyTo":"7v8vw5g4f0.fsf@alter.siamese.dyndns.org","subject":"Re: gsoc - Better git log --follow support","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-23T17:06:55Z","receivedAt":"2011-03-23T17:06:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 23, 2011 at 09:58:11AM -0700, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> >   # Now try it with --follow. Not so pretty.\n> >   git log --oneline --graph --follow builtin/add.c\n> \n> Is that an artifact of history simplification?\n\nI think it's a combination of factors. The lack of history\nsimplification is why the graph is all choppy. The insanely wide\nresults, though, are probably due to the problem you mention below.\n\n> I've always thought that it was because --follow hack used a single global\n> pathspec that flipped at a rename boundary,regardless of which part of the\n> history (i.e. the branch that was before the rename or after the rename)\n> it is following.  So if you have two branches merged together:\n> \n>         o---o---o---o---o---x---x---x\n>        /                   / \n>    ...o---o---o---x---x---x\n> \n> where commits marked with 'x' has it under the new path while commits\n> marked with 'o' has it under the old path, and start to dig the history\n> from the rightmost commit, the hack notices the rename at the transition\n> between the \"o---x\" on the upper branch and from then on keep digging the\n> history using the old path as the pathspec.  The commit history traversal\n> goes reverse-chronologically, so when inspecting the next commit, which is\n> the rightmost commit on the lower branch, the hack fails because it uses a\n> wrong pathspec (at that point it should still be using the new path as the\n> pathspec, but it already has switched to the old path).\n\nWhen I prototyped the multi-file --follow last summer, I added newly\nfound source paths to the pathspec list instead of replacing them.\nStrictly speaking, this can add unwanted commits when the names are\nre-used for unrelated files (either the source name is used on a\nparallel side branch, or the destination name is used in an earlier\nfile). But in practice it generates pretty good results, because those\ncorner cases don't tend to happen much. \n\nObviously a solution that always provides an exact right answer is\npreferable to \"pretty good results\", but we'd have to keep in mind the\nperformance difference.\n\n-Peff\n"},{"id":"164173","messageId":"7vk4fpemei.fsf@alter.siamese.dyndns.org","threadId":"26794","inReplyTo":"20110323170655.GA4392@sigill.intra.peff.net","subject":"Re: gsoc - Better git log --follow support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-23T18:12:37Z","receivedAt":"2011-03-23T18:12:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Obviously a solution that always provides an exact right answer is\n> preferable to \"pretty good results\", but we'd have to keep in mind the\n> performance difference.\n\nAnd that is why the current --follow hack was declared to be good enough\nto give \"pretty good results\" by its inventor, no?\n\nI still agree with it personally, and if we _were_ to improve it out of\n\"hack\" status, we should aim to do the right thing (provided if there is a\n\"right thing\" exists).\n"},{"id":"164179","messageId":"20110323182249.GA17490@sigill.intra.peff.net","threadId":"26794","inReplyTo":"7vk4fpemei.fsf@alter.siamese.dyndns.org","subject":"Re: gsoc - Better git log --follow support","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-23T18:22:49Z","receivedAt":"2011-03-23T18:22:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 23, 2011 at 11:12:37AM -0700, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > Obviously a solution that always provides an exact right answer is\n> > preferable to \"pretty good results\", but we'd have to keep in mind the\n> > performance difference.\n> \n> And that is why the current --follow hack was declared to be good enough\n> to give \"pretty good results\" by its inventor, no?\n\nAbsolutely. I just think we can make \"pretty good\" slightly better with\njust a little more effort.\n\n> I still agree with it personally, and if we _were_ to improve it out of\n> \"hack\" status, we should aim to do the right thing (provided if there is a\n> \"right thing\" exists).\n\nRight. The problem is that I'm not sure we want to pay the performance\npenalty to take it out of \"hack\" status. But that doesn't mean we can't\nmake it as good a hack as possible. :)\n\nActually, I think the non-hack version of it is not really --follow at\nall, but more like Bo's line-level browser. But I think that still\nleaves room for a solution like --follow that is perhaps a bit faster\nand provides a pretty good answer.\n\n-Peff\n"},{"id":"165781","messageId":"BANLkTik7t=Tfh_Y_+swnaAWyetfy8MU6VA@mail.gmail.com","threadId":"26794","inReplyTo":"AANLkTi=n7e70UqYU+6wpG4cu95fsg39tVM6=7fpfdZFz@mail.gmail.com","subject":"Re: gsoc - Better git log --follow support","fromName":"Michał Łowicki","fromEmail":"mlowicki@gmail.com","sentAt":"2011-04-13T21:04:20Z","receivedAt":"2011-04-13T21:04:20Z","isPatch":false,"sender":{"key":"mlowicki@gmail.com","avatar":"https://gravatar.com/avatar/dd126ae0130dbe5194e2965c12ebfef67128acdd40408e38d212d508cd831e13?d=mp&s=160"},"body":"Hi!\nThis is the first plan for this gsoc project. Jonathan Nieder\ndescribed me how --follow works and pointed me to a lot of sources for\nstudying. He also suggested where I should start a how it should look\nlike (thanks for that).\n\n25.04 - 15.06\n1) study the revision walking code\n    * understand its stages,\n    * improve Documentation/technical/api-revision-walking.txt (it\ndoesn't explain revision walking code stages so I could save others\nsome time in the future)\n\n2) study the pathspec matching + limiting and rename detaction API\n    * possiblity to update/improve documenation here as well\n\n3) figure out what state --follow will need to maintain, where it will\nfit into the revision walking process and design new architecture for\nit\n\n16.06 - 26-08\n4) implementation\n\nI plan to spend about 2 months for the first 3 points. It's all about\npoking the right developers and sending question to the mailing list.\nI'll try to send some updates soon when I get through some basic\nlecture and the most important code.\n\nAny suggestions/ideas are as always welcome. Be prepare for many\nquestions from my side :)\n\nGreetings,\nMichał Łowicki\n"},{"id":"165878","messageId":"20110415040649.GA25780@elie","threadId":"26794","inReplyTo":"BANLkTik7t=Tfh_Y_+swnaAWyetfy8MU6VA@mail.gmail.com","subject":"Re: gsoc - Better git log --follow support","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-15T04:06:49Z","receivedAt":"2011-04-15T04:06:49Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nMichał Łowicki wrote:\n\n> 25.04 - 15.06\n> 1) study the revision walking code\n[...]\n> 2) study the pathspec matching + limiting and rename detaction API\n[...]\n> 3) figure out what state --follow will need to maintain, where it will\n> fit into the revision walking process and design new architecture for\n> it\n\nIdeally this should happen in the next couple of days, rather than the\nnext couple of months.  Otherwise the project would be an unknown and\nit would be hard in good conscience to accept funding for it.\n\nThat said, I am personally willing to help out in the next few days\n(to help put a solid proposal together) and throughout the summer (to\nfix git log --follow) regardless.  I will be very happy when --follow\nworks reliably.\n\n> 16.06 - 26-08\n> 4) implementation\n>\n> I plan to spend about 2 months for the first 3 points. It's all about\n> poking the right developers and sending question to the mailing list.\n\nIt's hard to say how the process of studying code works.  Certainly\nasking a question can be a good way to start, and reading code can\nlead to more questions.  Another strategy that can work well is to\ntake the plunge and see what effect changes to the code have.\n\n> I'll try to send some updates soon when I get through some basic\n> lecture and the most important code.\n\nOk.  Remember it's okay to ask for help (though of course not so great\nto demand it) if you get stuck or have no idea where to start on\nsomething.\n\n> Any suggestions/ideas are as always welcome. Be prepare for many\n> questions from my side :)\n\nLooking forward to it.  If we end up with better technical\ndocumentation as a side effect, all the better.\n\nRegards,\nJonathan\n"},{"id":"165926","messageId":"BANLkTinPkGocaF71V9r0-XhY=wHUxJM1Bg@mail.gmail.com","threadId":"26794","inReplyTo":"20110415040649.GA25780@elie","subject":"Re: gsoc - Better git log --follow support","fromName":"Michał Łowicki","fromEmail":"mlowicki@gmail.com","sentAt":"2011-04-15T19:41:33Z","receivedAt":"2011-04-15T19:41:33Z","isPatch":false,"sender":{"key":"mlowicki@gmail.com","avatar":"https://gravatar.com/avatar/dd126ae0130dbe5194e2965c12ebfef67128acdd40408e38d212d508cd831e13?d=mp&s=160"},"body":"W dniu 15 kwietnia 2011 06:06 użytkownik Jonathan Nieder\n<jrnieder@gmail.com> napisał:\n> Hi,\n>\n> Michał Łowicki wrote:\n>\n>> 25.04 - 15.06\n>> 1) study the revision walking code\n> [...]\n>> 2) study the pathspec matching + limiting and rename detaction API\n> [...]\n>> 3) figure out what state --follow will need to maintain, where it will\n>> fit into the revision walking process and design new architecture for\n>> it\n>\n> Ideally this should happen in the next couple of days, rather than the\n> next couple of months.  Otherwise the project would be an unknown and\n> it would be hard in good conscience to accept funding for it.\n\nRight, I could try do this sooner but is it doable without deep\nunderstanding of 1 and 2?\n\n>\n> That said, I am personally willing to help out in the next few days\n> (to help put a solid proposal together) and throughout the summer (to\n> fix git log --follow) regardless.  I will be very happy when --follow\n> works reliably.\n\nGreat!\n\n>\n>> 16.06 - 26-08\n>> 4) implementation\n>>\n>> I plan to spend about 2 months for the first 3 points. It's all about\n>> poking the right developers and sending question to the mailing list.\n>\n> It's hard to say how the process of studying code works.  Certainly\n> asking a question can be a good way to start, and reading code can\n> lead to more questions.  Another strategy that can work well is to\n> take the plunge and see what effect changes to the code have.\n>\n>> I'll try to send some updates soon when I get through some basic\n>> lecture and the most important code.\n>\n> Ok.  Remember it's okay to ask for help (though of course not so great\n> to demand it) if you get stuck or have no idea where to start on\n> something.\n>\n>> Any suggestions/ideas are as always welcome. Be prepare for many\n>> questions from my side :)\n>\n> Looking forward to it.  If we end up with better technical\n> documentation as a side effect, all the better.\n>\n> Regards,\n> Jonathan\n>\n\n\n\n-- \nPozdrawiam,\nMichał Łowicki\n"}]}