Re: GSoC draft proposal: Line-level history browser

[Michael J Gruber <git@drmicha.warpmail.net>]

Bo Yang venit, vidit, dixit 30.03.2010 04:52:
> Hi Thomas,
> 
> On Tue, Mar 30, 2010 at 2:42 AM, Thomas Rast <trast@student.ethz.ch> 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