On Fri, Nov 09, 2007 at 10:35:00AM -0800, Junio C Hamano wrote: > Peter Baumann <waste.manager@xxxxxx> 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. Doh. Could have figured this out myself. But thank your for the explanation. -Peter - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
