Hi Thomas, 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. :) > I would, by far, prefer the latter. So far 'git log' has always been > noninteractive, and there's no really good way to make it interactive > because it also goes through the pager. (In the case of blame this is > solved in 'git gui blame', which might also be a reasonable approach.) > > OTOH, if you can really fake a history walk, then just about any > log-oriented tool should be able to work with it. You'd get graphical > output for free with gitk and git log --graph. I haven't really > thought through the ramifications, though. Ok, so let us try to abandon the interactive way totally. >> =====Work and technical issues===== >> ==Scenario== >> For how we use the line level browser and how the utility should act >> to us, here is an scenario: >> http://article.gmane.org/gmane.comp.version-control.git/143024/match=line+level+history+browser >> It contains code movement between files but not code copy and fuzzy matching. > > I would prefer if you could inline a short example, perhaps starting > at your second diff snippet. Examples are good ;-) > > Even if not, please drop the /match= parameter since it is very > distracting. I put the example at the end of the proposal as a reference. > >> 7. Reuse 'git log' existing options as many as possible. > > One thing that IMO is missing from this list, is a plumbing mode that > just feeds the raw data to a (presumed) frontend. It could be as > simple as supporting > > git log -L ... --pretty=raw --raw > > or similar, if this provides sufficient information. Compare 'git > blame --porcelain'. Very good feedback, I will add this, thanks a lot! > > This section is too handwavy for my taste. I think in most cases you > say "we can" when you really mean "git-blame already does it, so we > can just use a similar algorithm". Which is fine, but I'd rather see > it spelled out so as to see what is not already covered by blame's code. Changed in next version to make this clear. But only add some words to state that 'blame does similar' :) > > 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. :) >> April 26 - May 23: >> 1st week, follow the bird's eye view on Git's source code. >> 2nd week, have a look at the code of merge-base, analyze the rev-listmachinery >> 3rd week, have a look at builtin/log.c, >> 4th week, understand blame.c > > whether it be documenting your learnings in some way, improving docs > as you go, or documenting the APIs you find. Thanks a lot for this good advice, I will do so. With these feedback, I think I can make up a complete version of the proposal and submit it to Google. Thanks! Regards! Bo -- 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