Peter Baumann <waste.manager@xxxxxx> writes: > I tend to agree, but I'd like to also have somethin in the spirit of > "log.showroot = true" which handles the diff of the first commit like > diffing against an empty tree. Why should diff --cached differ from > this? At least it is easier to explain, just mention that diff --cached > shows everything which would become the next commit. I think it is _actively wrong_ to explain that "diff --cached shows everything which would become the next commit". It instills an incorrect mental model to new users. What would become the next commit is "git tar-tree $(git-write-tree)". A commit records the tree state, not difference from _the_ previous _single_ commit. Having said that, showing an "add everything" patch when the user says "git diff --cached" or even "git diff --cached HEAD" on a yet-to-be-born branch might actually make sense, although I am a bit afraid that the added inconsistency makes the command more confusing and harder to explain at the end. The output would become indistinguishable from the case where your previous commit indeed was with an empty tree. In essense, this is about making the state before the first commit less special. That may or may not be a good thing, and I agree that the preference on this may be related to what log.showroot controls. - 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