From: Junio C Hamano Date: Fri, 09 Nov 2007 18:35:00 GMT Subject: Re: Inconsistencies with git log Message-ID: <7vd4ujtgh7.fsf@gitster.siamese.dyndns.org> In-Reply-To: <20071109182248.GD28800@xp.machine.xx> Peter Baumann 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.