From mboxrd@z Thu Jan 1 00:00:00 1970 From: Junio C Hamano Subject: Re: [PATCH 1/3] Move bundle specific stuff into bundle.[ch] Date: Wed, 18 Jul 2007 00:26:54 -0700 Message-ID: <7v644i894x.fsf@assigned-by-dhcp.cox.net> References: <20070718032907.GY32566@spearce.org> <7vy7he8cjl.fsf@assigned-by-dhcp.cox.net> <20070718061931.GZ32566@spearce.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Daniel Barkalow , Johannes Schindelin , git@vger.kernel.org To: "Shawn O. Pearce" X-From: git-owner@vger.kernel.org Wed Jul 18 09:27:00 2007 Return-path: Envelope-to: gcvg-git@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1IB3w3-0008Ck-AZ for gcvg-git@gmane.org; Wed, 18 Jul 2007 09:26:59 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752736AbXGRH04 (ORCPT ); Wed, 18 Jul 2007 03:26:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752732AbXGRH04 (ORCPT ); Wed, 18 Jul 2007 03:26:56 -0400 Received: from fed1rmmtao106.cox.net ([68.230.241.40]:34813 "EHLO fed1rmmtao106.cox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752688AbXGRH0z (ORCPT ); Wed, 18 Jul 2007 03:26:55 -0400 Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao106.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070718072656.TCHS1393.fed1rmmtao106.cox.net@fed1rmimpo02.cox.net>; Wed, 18 Jul 2007 03:26:56 -0400 Received: from assigned-by-dhcp.cox.net ([68.5.247.80]) by fed1rmimpo02.cox.net with bizsmtp id QvSu1X00L1kojtg0000000; Wed, 18 Jul 2007 03:26:55 -0400 In-Reply-To: <20070718061931.GZ32566@spearce.org> (Shawn O. Pearce's message of "Wed, 18 Jul 2007 02:19:31 -0400") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: "Shawn O. Pearce" writes: > Yea, this I like even better than what I posted. Now we just need > a suck^H^H^H^Hprogrammer to implement a working prototype and see > how folks like more realistic diffs generated with it. ;-) I have to disgree. We on the git list *live* in pretty much git-only world (ok, I am ignoring git-svn people for now ;-)), so it might feel it beneficial to add a new output format to git-diff. But many users of git generated patch needs to interact with patches that are not generated by git. I think an additional postprocessor in patchutils/interdiff toolchest would probably make much more sense. Then a person who reviews a patch that is supposed to be line movement can use the filter to verify the parts that should be only line movements are indeed are movements and nothing else. Speaking of "diff" output, what I would like to see is a support of 'copied context' (i.e. traditional 'context diff' format you would get from "diff -c"), in addition to the 'unified context' we support. Generating copied context may help people who need to give patches to others that accept only copied context format patches (are there important projects that take only cpied context format patches?). Being able to accept copied context format patches in 'git-apply' would also be handy. Of course, we could use interdiff to mangle copied context format into unified context format, so 'git-apply' is not a big deal, though.