Re: git diff with add/modified codes

[Jakub Narebski <jnareb@gmail.com>]

On Sat, 28 July 2007, Jon Smirl wrote:
> On 7/28/07, Jakub Narebski <jnareb@gmail.com> wrote:
>> Jeff King wrote:
>>
>>> On Fri, Jul 27, 2007 at 08:17:54PM -0400, Jon Smirl wrote:
>>>
>>>> That's not what I want. I'm looking a report that indicates new files
>>>> vs modified ones in a single list. These old patches I am working with
>>>> often create 100 files and modify another 200.
>>>>
>>>> Adding a code like (Added (A), Copied (C), Deleted (D), Modified (M),
>>>> Renamed (R))  to --stat would be perfect.
>>>
>>> How about --name-status?
>>
>> Or -r --name-status?
> 
> -r is not in the git diff doc but it is used in the examples.
> http://www.kernel.org/pub/software/scm/git/docs/git-diff.html

<quote>
  <2> show only names and the nature of change, but not actual
  diff output.  --name-status disables usual patch generation
  which in turn also disables recursive behavior, so without -r
  you would only see the directory name if there is a change in a
  file in a subdirectory.
</quote>

"Of course" one knows that "git diff <tree-ish> <tree-ish>" is
git-diff-tree in disguise, and accepts git-diff-tree options.

By the way, I was thinking about extending --numstat output to include
also status. Current --numstat output is ill fitted to deal with renames
and copies, at least ill fitted for machine consumption of renames
output; it uses "old_name => new_name" as a filename for renames. While
it would be fairly easy to put pre- and after-rename names separated
by TAB, and quoted if needed (including embedded TAB character in
the filename, which would be quoted as \t instead) without breaking
anu current --numstat output parsers (although I don't think any of
them uses -M/-C), it would be hard to do the same for --numstat -z output.
A solution (not best, I admit) would be to use NUL NUL to separate pre-
and post-image filename, but I think it would be best to add new
--numstat-extended format to git-diff.

P.S. Is binary diff output described somewhere?
-- 
Jakub Narebski
Poland