On Sat, Oct 01, 2011 at 11:03:18PM +0200, Zbigniew J??drzejewski-Szmek wrote: > [cc: Paul Mackerras] > > Hi, > I think that the historical explanation that Junio gave could > be used as a basis for a commit message: > > In early days, all projects managed by git (except for git itself) had the > product of a fairly mature development history in their first commit, and > it was deemed unnecessary clutter to show additions of these thousands of > paths as a patch. > > "git log" learned to show the patch for the initial commit without requiring > --root command line option at 0f03ca9 (config option log.showroot to show > the diff of root commits, 2006-11-23). > > Teach gitk to respect log.showroot. Absolutely, that would be a much better commit message. I'll wait and see if there are more comments and then resubmit. > Also the gitk should be mentioned in the man-page for git-config log.showroot. > The current description of this option seems suboptimal because it explains > how it used to be, which is not really relevant: > log.showroot > If true, the initial commit will be shown as a big creation event. This is > equivalent to a diff against an empty tree. Tools like git-log(1) or git- > whatchanged(1), which normally hide the root commit will now show it. True by > default. > This could be changed to: > If true (the default), the root commit will be shown as a big creation > event --- a diff against an empty tree. This diff can be very large for > a project which was imported into git after some development history. > If log.showroot is false tools like git-log(1), git-whatchanged(1), or > gitk(1) will not display the added files. I agree, but that feels like something that could be made into a separate patch. Or should I include that too? Marcus -- 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