Re: Inconsistencies with git log

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Nov 9, 2007, 18:36 UTC
Message-ID: <alpine.LFD.0.999.0711091029160.15101@woody.linux-foundation.org>
In-Reply-To: <20071109182248.GD28800@xp.machine.xx>

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