Re: [PATCH v7] Add new git-related helper to contrib

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

On Thu, May 30, 2013 at 4:01 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Let's do one more review.
>
> Felipe Contreras wrote:
>> diff --git a/contrib/related/git-related b/contrib/related/git-related
>> new file mode 100755
>> index 0000000..1b9b1e7
>> --- /dev/null
>> +++ b/contrib/related/git-related
>> @@ -0,0 +1,120 @@
>> +#!/usr/bin/env ruby
>> +
>> +# This script finds people that might be interested in a patch
>> +# usage: git related <file>
>> +
>> +$since = '5-years-ago'
>> +$min_percent = 10
>> +
>> +class Commit
>> +
>> +  attr_reader :persons
>
> Unless you plan to introduce many more fields (I haven't looked at the
> later patches), you might as well implement an #each, like in Commits.

commit.each doesn't make sense; each what?

We could do 'commit.each_person', but why is that so better than
commit.persons.each? It's not.

>> +    data.each_line do |line|
>> +      if not msg
>> +        case line
>> +        when /^author ([^<>]+) <(\S+)> (.+)$/
>> +          @persons << '%s <%s>' % [$1, $2]
>
> Why capture the third group when $3 is unused?

Completeness.

>> +        when /^$/
>> +          msg = true
>> +        end
>> +      else
>> +        if line =~ /^(Signed-off|Reviewed|Acked)-by: ([^<>]+) <(\S+?)>$/
>> +          @persons << '%s <%s>' % [$2, $3]
>
> Why capture the first group when $1 is unused?

You want to complicate the regex even more with:

/^(?:Signed-off|Reviewed|Acked)-by: ([^<>]+) <(\S+?)>$/

For what purpose?

>> +        end
>> +      end
>> +    end
>> +    @persons.uniq!
>> +  end
>> +
>> +end
>> +
>> +class Commits
>> +
>> +  def initialize
>> +    @items = {}
>> +  end
>> +
>> +  def size
>> +    @items.size
>> +  end
>> +
>> +  def each(&block)
>> +    @items.each(&block)
>> +  end
>> +
>> +  def import
>> +    return if @items.empty?
>> +    File.popen(%w[git cat-file --batch], 'r+') do |p|
>
> Don't you need rb+ to suppress the CRLF nonsense on Windows?

Who knows.

>> +      p.write(@items.keys.join("\n"))
>
> As you might have realized, the parentheses are optional everywhere
> (except when it is required for disambiguation).  I'm merely pointing
> it out here, because this line looks especially ugly.

I suspect most Git developers would prefer the traditional function call style.

>> +      p.close_write
>> +      p.each do |line|
>> +        if line =~ /^(\h{40}) commit (\d+)/
>> +          id, len = $1, $2
>
> id, len = $1, Integer $2.  And drop the .to_i on the next line.

This is way is better.

>> +          data = p.read($2.to_i)
>> +          @items[id].parse(data)
>> +        end
>> +      end
>> +    end
>> +  end
>> +
>> +  def get_blame(source, start, len, from)
>> +    return if len == 0
>> +    len ||= 1
>
> I asked you to use 'len =1 if not len' for clarity, but you didn't like it.

git grep "||=" disagrees.

>> +    File.popen(['git', 'blame', '--incremental', '-C', '-C',
>> +               '-L', '%u,+%u' % [start, len],
>> +               '--since', $since, from + '^',
>> +               '--', source]) do |p|
>> +      p.each do |line|
>> +        if line =~ /^\h{40}/
>> +          id = $&
>> +          @items[id] = Commit.new(id)
>> +        end
>> +      end
>> +    end
>> +  end
>> +
>> +  def from_patch(file)
>> +    from = source = nil
>> +    File.open(file) do |f|
>> +      f.each do |line|
>
> File.readlines(file).each do |line|.

That's less efficient.

>> +        when /^---\s+(\S+)/
>> +          source = $1 != '/dev/null' ? $1[2..-1] : nil
>> +        when /^@@ -(\d+)(?:,(\d+))?/
>> +          get_blame(source, $1, $2, from) if source and from
>
> Useless capture.  When is len ($2) going to be nil?

Junio already went over it, see the diff format.

What's your objective? Block this patch from ever going in?

Not a single one of these comments makes a difference at all, all of
them can wait until after the patch is merged, many of them are a
matter of preferences, and some of them have already been addressed as
precisely that: disagreements in style.

-- 
Felipe Contreras