On Wed, Dec 20, 2006 at 12:14:14AM -0800, Junio C Hamano wrote:
> > Also, should this instead be diff.fulldiff?
>
> Probably not.
Based on your explanation, I think that makes sense.
> > Also also, I was going to submit a patch to document --full-diff,
> > but I had a few questions. Should it go in diff-options? That makes some
> > sense to me, but the parsing actually happens in setup_revisions.
>
> Not at all.
Then where should it go? whatchanged and log have a great deal of
overlap in terms of parsing, but they don't seem to share any
documentation (or note the fact that git-whatchanged is basically just
git-log -p).
> > Furthermore, it seems to do the same thing as --pickaxe-all. Should we
> > try to combine these?
>
> No.
Thanks for the thorough explanation. I think this makes my config option
description a little bit off, then, since it doesn't actually show all
of the changed files for a commit in the case of pickaxe.
What has me confused, then, is that you said this:
> I typically do:
>
> git log --full-diff -p -SCOLLISION
>
> The --full-diff option helps because it shows the diff for other
> files (that do not have different number of substring COLLISION
> in the pre and postimage) in the same commit as well.
But that isn't the case, AFAIK (e.g., the command line you mention shows
only changes to sha1_file.c in commit aac17941, but cache.h was also
changed). Did you mean --pickaxe-all?
> Your understanding needs to be clarified on how paths are
> filtered, and how log family and diff interacts, and probably
> these need to be better documented.
To be honest, I'm not sure when one would really _want_ the flexibility
this provides. It might be more intuitive to git-{log,whatchanged} users
to have a single option (config and command line) to set --full-diff and
--pickaxe-all together. At the very least, I think I now want a
diff.pickaxeall config option.
-Peff
-
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