Subject: Re: Inconsistencies with git log

From: Jakub Narebski <[email-masked]>
Date: Fri, 09 Nov 2007 19:37:58 +0100

Junio C Hamano wrote:

> Peter Baumann <[email-masked]> writes:
> 
>> 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.
> 
> The answer is "merges".
> 
> If a merge does not change the tree from one of the ancestors,
> the side branches are pruned out, to give you _one_ explanation
> of how you got there.  And by pruning such side branches, you
> get the simpler explanation.
> 
> Linus gave the example of "log origin/pu ."; there is at least
> one merge I am aware of that did not change any path (it is the
> one that merges "jc/maint-format-patch-encoding" topic).  With
> the path limiter, the merge commit and the two commits that
> leads to it on the side branch are hidden away.

Does it mean that "git log" and "git log --full-history ." produce
the same output?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git