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

From: Jakub Narebski <jnareb@gmail.com>
Date: Apr 13, 2008, 20:43 UTC
Message-ID: <200804132243.40909.jnareb@gmail.com>
In-Reply-To: <20AD7252-19A2-443F-88CF-F871AE7A392E@nocrew.org>

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

Dnia niedziela 13. kwietnia 2008 20:44, Fredrik Noring napisał:

Show 20 quoted lines

> 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?

Show 5 quoted lines

> 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