Re: Recent unresolved issues

From: Junio C Hamano <junkio@cox.net>
Date: Apr 15, 2006, 01:35 UTC
Message-ID: <7vacanmxhe.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0604141748070.3701@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 11 quoted lines

> On Fri, 14 Apr 2006, Junio C Hamano wrote:
>> 
>> I was thinking long because I had an impression that anything
>> based on revision.c interface, if it wants to do a tree-diff on
>> the commit stream, would need two different diff options.  One
>> is used by revision.c internally so that it can use its own
>> add_remove/change for parent pruning, and another to control the
>> way diff is run by the user of revision.c.
>
> I think you're right, and I've probably broken "--full-diff" (causing the 
> revparse to also use the empty set of paths). Gaah.

Another thing is that some revision.c users are not interested in taking diff options at all.

I was going to suggest a new structure that captures struct rev_info, struct log_tree_opt and miscellaneous bits cmd_log uses such as do_diff, full_diff, etc., and move the option parser out of cmd_log() to a separate function, and have that shared across cmd_log(), cmd_show(), cmd_whatchanged(), and cmd_diff() without affecting any of the existing revision.c users. That way, "rev-list --cc HEAD" will remain nonsense.

One nice property your approach has is that it makes "git diff-tree a..b" magically starts working, unlike what I suggested above.