Re: What's new in git.git

From: Junio C Hamano <junkio@cox.net>
Date: Feb 6, 2006, 16:58 UTC
Message-ID: <7vbqxk8lvg.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0602060754470.3854@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 10 quoted lines

> On Sun, 5 Feb 2006, Junio C Hamano wrote:
>> 
>>  * Add -c and --cc to diff-tree and diff-files.  They give the
>>    "combined diff" output that shows merges more human readably.
>
> Btw, the only concern I have left about "-c" and "--cc" is that I don't 
> think the old merge-diff behaviour makes any sense at all, and that we 
> should drop it entirely in favour of "-c" and "--cc".
> ...
> Has anybody on the git list ever used "-m" with git-diff-tree? Speak up..

One thing that makes me a bit reluctant is that I am not as confident as you are about -c doing the right thing. I have not examined differences between -m -p and -c, especially under various combinations of other flags like -B, -C and -M. I did compare output from -c and --cc to check if the logic to drop "uninteresting" hunks are doing the right thing and I am reasonably sure that part is good, though.

The code to do -c punts at showing type changes, and there is no filemode information in the output either. So far nobody has complained about it, and a type change would be a rare thing anyway and might not matter in practice. We should however not just silently ignore rare cases that we do not handle. Instead we should raise a big red flag; otherwise the rare cases in which -c cheats can go unnoticed, which feels wrong.

Having said that, the above concern is primarily about debugging the -c implementation and for that we could always fall back on running "diff-tree -p H H^2" by hand, so maybe dropping "-m -p" is an OK thing to do from that point of view.

People who are doing SCM migration part might be using it as a replacement for "for i; do diff-tree -p H H^$i; done" to extract diffs from each parent with a single command, though...