Re: [PATCH v7] Add new git-related helper to contrib
- From
Felipe Contreras <felipe.contreras@gmail.com>
- Date
- May 30, 2013, 11:31 UTC
- Message-ID
- <CAMP44s25vX1p1Np7yqc9_AqVBme+MCTY88hjhfWdL6KZkxgs7Q@mail.gmail.com>
- In-Reply-To
- <CALkWK0=ZbOy6sXOvnTNAqz_UBsUymY1CR_WczT-O3Q+18HJjzQ@mail.gmail.com>
On Thu, May 30, 2013 at 4:01 AM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:
Show 23 quoted lines
> 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.
Show 7 quoted lines
>> + 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.
Show 8 quoted lines
>> + 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?
Show 27 quoted lines
>> + 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.
Show 5 quoted lines
>> + 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.
Show 6 quoted lines
>> + 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.
Show 12 quoted lines
>> + 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.
Show 19 quoted lines
>> + 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.
Show 6 quoted lines
>> + 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