Re: Inconsistencies with git log

[Peter Baumann <waste.manager@gmx.de>]

On Fri, Nov 09, 2007 at 09:53:00AM -0800, Linus Torvalds wrote:
> 
> 
> On Fri, 9 Nov 2007, Linus Torvalds wrote:
> > 
> > In fact, even at the top-of-tree, "git log" and "git log ." are two 
> > totally different things [...]
> 
> Btw, the reason (and really the *only* reason) this is interesting at all 
> is just to show that the notion of "full history" and "relative pathnames" 
> really have nothing to do with each other. They really are in totally 
> different and orthogonal dimensions.
> 
> "Full history" is something that exist *independently* of the pathnames. 
> 
> So the fact is, "git log" on its own is really about the *project*. It is 
> totally pathname-independent, and I'd argue that many people are often 
> just interested in the explanations (even though you obviously can also 
> see the patches and the files changed too!) so I seriously doubt that this 
> is just an implementation issue or my personal hang-up.
> 
> In other words "git log" simply is something *global*. It doesn't matter 
> where in the tree you are, the end result is the same - it's about the 
> project as a whole.
> 
> In contrast, "git log <filename>" is fundamentally different. Now you're 
> explicitly stating that it's not something global any more, and that it's 
> about the *files*. That's also why "git log" and "git log ." are acually 
> different even at the top level.
> 
> Because when you're interested in the files, by implication you're not 
> interested in commits that don't change the files - and there can be such 
> commits even when you give the *total* file list.  
> 

Hm. I tried to run your 'git log' and 'git log .' example and a diff
revealed that the output of those two isn't the same, contrary to what I
thought.

In the 'git-log .' case, there should be done a history simplification,
but then only commits which don't change anything are pruned and AFAIR
'git commit' doesn't allow this. Using core git, one could create commits
with the same tree as their parent, but I don't think that all the commits
which get removed in the '.' case where produced that way. There has to be
another case I can't figure out.

A little confused,
Peter