Re: Inconsistencies with git log

[Junio C Hamano <gitster@pobox.com>]

Peter Baumann <waste.manager@gmx.de> 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.