Re: [PATCH] Calculate lines changed for cvs log command

[Jakub Narebski <jnareb@gmail.com>]

Could you please do not toppost?  It is against natural reading order.

Dnia niedziela 13. kwietnia 2008 20:44, Fredrik Noring napisał:
> 13 apr 2008 kl. 18.59 skrev Jakub Narebski:
>> Fredrik Noring <noring@nocrew.org> writes:
>>
>>> (My mailer destroys inline patches, so I'm attaching it. Sorry about
>>> that.)
>>
>> Could you please attach it as 1.) attachement=inline if possible, to
>> have them displayed along the email; 2.) use text/plain mimetype, not
>> application/octet-stream (you might need to change patch extension
>> from *.patch to *.txt; you can change default extension of files
>> generated by git-format-patch via format.suffix configuration
>> variable), and what is tied with it 3.) use Transfer-Encoding: 8bit
>> (or something like that), not base64, and preferably not
>> quoted-printable?
>>
>> Or change your mailer (or configure it), or use git-send-email.
>> 
> OK, I'll look deeper into the mailer issues. Any comments on the  
> actual code in the patch, and the question regarding git-log vs git- 
> cat-file?

First, having patch as attachement, moreover as _binary_ and _encoded_ 
attachement makes it hard to comment on it.  And if you make it hard to 
comment on patch, people woundn't do it.

Second, your approach with "--pretty=format:%s%n%b" might be a good
idea, but you don't get all the information as you get from 
git-cat-file: no tree info, no true (recorded) parents info, no 
committer info, no author info.  I don't know if git-cvsserver makes 
use of that info or not; from the patch it looks as if it discards
all but commit message (message body). 

BTW. I'm not Perl expert, but if you want to discard two last
elements in arrays, wouldn't using splice (or just decreasing
$#lines by 2) be simpler solution?

> Speaking of which -- is there any particular reason for not running  
> git-log once, instead of forking it (or git-cat-file) for every commit  
> in the log? There seems to be a special case for merges, but it'd  
> appear to be more efficient to query the SQLite DB for the commits  
> provided by git-log rather than the other way around, no?

About git-log vs git-cat-file: take a look how gitweb does it, with 
parse_commits and parse_commit_text, and commit 756bbf548dbef5b738c
by Robert Fitzsimons introducing it.  Note that IIRC this commit
predates --pretty=format:<fmt> option to git-log / git-rev-list.

> Any thoughts?
> 
> (git-send-email appears to fail for me without providing an error.)

You have either configure sendmail, or set mail.smtp* options (or 
something like that) correctly.

BTW. cannot you turn off "format=flowed" in Apple Mail?
-- 
Jakub Narebski
Poland