git log vs git diff vs --name-status

git log vs git diff vs --name-status

[VMiklos]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

hi,

$ git diff HEAD --name-status
M       dir/foo1

then i commit this change, and git log says:

$ git log --name-status -1
commit c9128f447c614d5b085286d9d7e84a643fbaea92
Author: VMiklos <vmiklos@frugalware.org>
Date:   Thu Aug 23 10:41:38 2007 +0200

    foo

M       dir

only. no /foo1. also is the file is dir/subdir/file1, then only "M dir"
is shown. is this inconsistency expected?

yes, i know that using --stats this problem could go away, but i speak
about --name-status

thanks,
- VMiklos

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: git log vs git diff vs --name-status

[VMiklos]

[-- Attachment #1: Type: text/plain, Size: 149 bytes --]

Hello,

Na Thu, Aug 23, 2007 at 10:43:15AM +0200, VMiklos <vmiklos@frugalware.org> pisal(a):
> M       dir

sorry, i needed the -r option

- VMiklos

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: git log vs git diff vs --name-status

[Junio C Hamano]

VMiklos <vmiklos@frugalware.org> writes:

> Na Thu, Aug 23, 2007 at 10:43:15AM +0200, VMiklos <vmiklos@frugalware.org> pisal(a):
>> M       dir
>
> sorry, i needed the -r option

I know.

I've been debating myself if --name-status should imply -r
(recursive behaviour) for "git log".  More specifically, I think
a reasonable guiding principles would be something like:

 * Anything that looks at the file contents level change (that
   is, -p, --stat and --numstat) should always imply recursive;

 * Anything that is Porcelain should always imply recursive.

I am fairly certain about the first one, but not absolutely sure
about the latter.  The first principle does not justify making
your example to recurse, but the second, if we accept it, would.

Re: git log vs git diff vs --name-status

[VMiklos]

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

Hello,

Na Thu, Aug 23, 2007 at 02:33:38AM -0700, Junio C Hamano <gitster@pobox.com> pisal(a):
>  * Anything that is Porcelain should always imply recursive.
> 
> I am fairly certain about the first one, but not absolutely sure
> about the latter.  The first principle does not justify making
> your example to recurse, but the second, if we accept it, would.

well, i'm not one who should decide this, but i like the idea, i see no
case when not implying recursive in the Porcelain layer can be useful

- VMiklos

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]