On Fri, 9 Nov 2007, Peter Baumann wrote: > > 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. Btw, you can *make* them the same by using git log --full-history --sparse . which basically tells git that you do not want any of the history simplification that git log does by default. There's two different kinds of simplifications (which is why there are two kinds of switches above): - the "simplify merges to just the parent that is identical" This basically means that if a merge result comes 100% from one of the parents, by default we will only look at that parent. Using --full-history avoids this. - the "dense" history, which removes simple commits that don't make any changes This is the "--sparse" thing: it says that we're interested even in regular commits that simply don't make any changes. > 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. Actually, git itself creates these commits under several circumstances: - you can *force* it. No, "git commit" on its own doesn't allow it, but you can do it quite easily with "git commit-tree" and setting things up by hand. - you can import history from other SCM's. I think all importers will honor other SCM's, and if they allow empty commits then the end result will have empty commits in it too! - merges. This is the common case. You have a "git merge --ours" or similar, which basically merges just one side (or, even without "--ours", this is really common for the non-"." case: a merge just doesn't touch some files at all). Then, the merge simplifier will first turn it into a "single parent", and then densification will remove that (now uninteresting) empty merge. > 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. See above. Three cases, in fact. Linus - 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
