Re: Inconsistencies with git log

On Wed, 7 Nov 2007, Jon Smirl wrote:

On 11/7/07, Johannes Schindelin [off-list ref] wrote:

quoted

Hi,

On Wed, 7 Nov 2007, Jon Smirl wrote:

quoted

On 11/7/07, Johannes Schindelin [off-list ref] wrote:

quoted

We also tend to take the approach of viewing the history as that of
the whole project.

But if you type 'git log' while cd'd into a subdirectory the whole log
is almost never what you want. It's this kind of thing that makes git
harder to use.

When I am working in a subdirectory, I often want the whole history.  For
example, when I am working on the documentation, sometimes I need to look
up a commit real quick, that touched other parts.

Besides, adding a space and a dot is not what qualifies for "harder to
use" with this developer.

So if git log is always whole tree, why doesn't this work?

 cd arch/powerpc/platforms/52xx
 git log arch/powerpc/platforms/52xx
fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
revision or path not in the working tree.
Use '--' to separate paths from revisions

It's not consistent. git log with no parameters is relative to the
project root, git log with a parameter is relative to the current
directory.

git log with no parameters is still relative to the current directory. 
It's just not limited by paths at all, so what it's relative to doesn't 
matter.

Since it shows is commits that change any of the given paths, the 
perfectly consistant thing to do without any paths would be to show no 
commits. Of course, that's totally useless, so we default to making no 
limitation instead.

If there were any other options that took paths or filenames, they'd be 
relative to the subdirectory, regardless of whether there were any paths, 
and having no paths would still show history for the project without 
regard to whether commits touch paths.

	-Daniel
*This .sig left intentionally blank*