Re: [PATCH v9 3/4] contrib: related: add option to parse from committish

[Felipe Contreras <felipe.contreras@gmail.com>]

On Mon, Jun 3, 2013 at 2:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> For example master..feature-a.
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>>  contrib/related/git-related | 38 ++++++++++++++++++++++++++++++++++++--
>>  1 file changed, 36 insertions(+), 2 deletions(-)
>>
>> diff --git a/contrib/related/git-related b/contrib/related/git-related
>> index 3379982..20eb456 100755
>> --- a/contrib/related/git-related
>> +++ b/contrib/related/git-related
>> @@ -1,10 +1,12 @@
>>  #!/usr/bin/env ruby
>>
>>  # This script finds people that might be interested in a patch
>> -# usage: git related <files>
>> +# usage: git related <files | rev-list options>
>>
>>  $since = '5-years-ago'
>>  $min_percent = 10
>> +$files = []
>> +$rev_args = []
>>
>>  class Commit
>>
>> @@ -102,10 +104,42 @@ class Commits
>>      end
>>    end
>>
>> +  def from_rev_args(args)
>> +    source = nil
>> +    File.popen(%w[git rev-list --reverse] + args) do |p|
>> +      p.each do |e|
>> +        id = e.chomp
>> +        @main_commits[id] = true
>> +        File.popen(%w[git show -C --oneline] + [id]) do |p|
>
> Is there a solid design choice behind -C, or is it just what happens
> to have worked for you in practice?  If the former, it may want to
> be explained somewhere (either in the log or in the code) so that
> later tweaks will not break it, especially given that the invocation
> of blame seems to use double-C's.

No reason in particular.

-- 
Felipe Contreras