>> > git log --stat -- A >> >> very handy indeed. >> >> I was surprised on initial use that --stat is >> limited to the file specified in "A" and doesn't >> expand to describe the entire commit that touches "A". >> (ie. the stat output is a subset of what is associated >> with the displayed commit comments). >> >> This, of course, is clear now, it just isn't what >> I expected on first use. > >Well, you can obviously have your cake and eat it too (ie >"--full-diff"). > >I don't often end up using the "--full-diff" thing. It's almost never >actually worth it until I find the diff that I actually start caring >about, and the full diff just makes it harder to see the part >I explicitly told git I was interested in. sounds good. >So the default "show only diffs for the files asked for" >behaviour is in my opinion much superior (and it used to be the only one), >because the "show the whole thing" part ends up being something you use only once >you've already skimmed the default case and decide to go deeper. I agree. >Of course, "gitk" ends up using the full diff by default in its diff >window. I'm not convinced that's the right thing, but usually >when I use gitk I'm primarily looking at the history and the commit >messages to decide if it's a relevant one, not the diff, so I don't think >it matters. Yeah, I agree that gitk is fine how it is. The only part I don't agree with above is the word "obviously". '--full-diff --stats' didn't jump out at me from the man page. To be fair, yes, I should probably take the time to read the docs through and not rely on the man pages, they've changed a lot since I last looked. -Len - : 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