Bo Yang venit, vidit, dixit 30.03.2010 04:52: > 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. :) You may want to create your repo as a fork of gitster/git instead. That's easier on github, they have a hard time anyways these days ;) Seriously, it helps making use of their network feature etc. I don't have anything to add to your proposal (I like it), but I'll be at NKU next week (Conference @ Chern Institute) so drop me a PM if you wish. Cheers, Michael -- 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