Bo Yang <struggleyb.nku@xxxxxxxxx> writes: > On Tue, Mar 30, 2010 at 2:42 AM, Thomas Rast <trast@xxxxxxxxxxxxxxx> wrote: > > > > Is this really the right use-case? AFAICT the answer to the implied > > question is given by simply running 'git blame -M 93fc05e:pretty.c'. > > > > (Coming up with a better example should be easy; the way I currently > > think of the feature means that it will mostly replace git-blame for > > me...) > > I will cite the same example below in the scenario. :) By the way, it would be good to find an example with "evil merge", which means that the change to given line(s) is in the merge commit itself. Correctly simplifying history in such case might be non-trivial. Another example that it would be good to have is "history split" example, which means the case where some lines were consolidated (e.g. after refactoring), and some of lines in "preimage" come from different lines of history. This would help with writing tests for this feature (compare tests for blame), although they are not in my opinion necessary for the proposal itself. I hope that all this cases would fall naturally from the implementation. [...] > > Push the code somewhere public as you go, even between feature > > completions. Post RFCs once you have workable features so people can > > comment. Generally try to be visible. > > > > Bonus points if you can think of something visible to do during the > > period where you look at code, > > Yeah, really is a good point. And I have tried to play around on > github.com and try to set up a http://github.com/byang/my_git for this > purpose. :) my_git is not very descriptive... well, unless you would do your work on GSoC2010/line-level-history-browser branch, or something like that. It might be good idea to have repo.or.cz as an additional repository, as a fork of git.git repo, and with SoC / GSoC labels. See http://repo.or.cz/w/git.git/forks?t=soc -- Jakub Narebski Poland ShadeHawk on #git -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html