From mboxrd@z Thu Jan 1 00:00:00 1970 From: Junio C Hamano Subject: Re: What's in git.git Date: Thu, 26 Jan 2006 04:12:53 -0800 Message-ID: <7vhd7rfare.fsf@assigned-by-dhcp.cox.net> References: <7vy814qx6o.fsf@assigned-by-dhcp.cox.net> <8aa486160601250634v294857e0j@mail.gmail.com> <7vvew7lv4s.fsf@assigned-by-dhcp.cox.net> <8aa486160601260104v745594d9m@mail.gmail.com> <7vk6cngwfh.fsf@assigned-by-dhcp.cox.net> <8aa486160601260156h6157ca34s@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: git@vger.kernel.org X-From: git-owner@vger.kernel.org Thu Jan 26 13:13:58 2006 Return-path: Envelope-to: gcvg-git@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F260W-0002kD-KT for gcvg-git@gmane.org; Thu, 26 Jan 2006 13:13:45 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751336AbWAZMM4 (ORCPT ); Thu, 26 Jan 2006 07:12:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751340AbWAZMM4 (ORCPT ); Thu, 26 Jan 2006 07:12:56 -0500 Received: from fed1rmmtao09.cox.net ([68.230.241.30]:26069 "EHLO fed1rmmtao09.cox.net") by vger.kernel.org with ESMTP id S1751336AbWAZMMz (ORCPT ); Thu, 26 Jan 2006 07:12:55 -0500 Received: from assigned-by-dhcp.cox.net ([68.4.9.127]) by fed1rmmtao09.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060126121258.WQOM25099.fed1rmmtao09.cox.net@assigned-by-dhcp.cox.net>; Thu, 26 Jan 2006 07:12:58 -0500 To: Santi Bejar User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: Santi Bejar writes: > 2006/1/26, Junio C Hamano : >> No comment on your message yet, but please fix your MUA so that >> your messages do not get rejected by the mailing list software. >> >> I suspect it is base64 CTE that causes it. >> >> Content-Type: text/plain; charset=UTF-8 >> Content-Transfer-Encoding: base64 > > Sorry, about that. But I didn't get any notification. You do not need to feel sorry. It's just your voice is not heard as widely as it should have been, and you did not know about it. The spam filter just drops things on the floor without bothering to notify potential spammers. I think this patch would address your two issues (applies on top of "pu"), but I have not had time to test it seriously enough. -- >8 -- [PATCH] combine-diff: better hunk splitting. It considered an otherwise unchanged line that had line removals in front of it an interesting line, which caused hunks to have one extra the trailing context line. Signed-off-by: Junio C Hamano --- combine-diff.c | 142 ++++++++++++++++++++++++++++++++++++++++++++++---------- 1 files changed, 116 insertions(+), 26 deletions(-) 0aa20bc0c276c3fcb7215ba9f591960178792261 diff --git a/combine-diff.c b/combine-diff.c index 3b219a0..d94a93d 100644 --- a/combine-diff.c +++ b/combine-diff.c @@ -323,52 +323,142 @@ static unsigned long line_all_diff(struc return different; } -static int make_hunks(struct sline *sline, unsigned long cnt, - int num_parent, int dense) +static unsigned long adjust_hunk_tail(struct sline *sline, + unsigned long all_mask, + unsigned long hunk_begin, + unsigned long i) +{ + /* i points at the first uninteresting line. + * If the last line of the hunk was interesting + * only because it has some deletion, then + * it is not all that interesting for the + * purpose of giving trailing context lines. + */ + if ((hunk_begin + 1 <= i) && + ((sline[i-1].flag & all_mask) == all_mask)) + i--; + return i; +} + +static unsigned long next_interesting(struct sline *sline, + unsigned long mark, + unsigned long i, + unsigned long cnt, + int uninteresting) +{ + while (i < cnt) + if (uninteresting ? + !(sline[i].flag & mark) : + (sline[i].flag & mark)) + return i; + else + i++; + return cnt; +} + +static int give_context(struct sline *sline, unsigned long cnt, int num_parent) { unsigned long all_mask = (1UL<