Jeff King <peff@xxxxxxxx> writes: > On Tue, Nov 03, 2009 at 09:49:46PM -0800, Junio C Hamano wrote: > >> Even though I personally find the stat information very useful, I would be >> happier if somebody reverts the bg/format-patch-p-noop series and instead >> fixes the regression caused by 68daa64, and does so without touching any >> output from the low-level plumbing like diff-tree that may be used by >> scripts. > > I agree that 68daa64 is a hack (and I even noted in the commit log that > "-p" is now a no-op). Correct, and thanks---it was not your fault and I didn't mean to blame you. If anything it was mine. > The problem is that we don't have the one critical > bit of information in cmd_format_patch that we do in diff_opt_parse: was > the format set explicitly, or was it a side-effect of -U (or --binary, > or maybe others). The appoarch your "how about this" takes feels right. We did discuss "set of hardwired defaults specific to the individual commands, that are masked by set of defaults read from the config, that are in turn masked by set of command line options", but I do not think that level of complexity is worth for this "is it -U<n> or -p" issue. > My test case checks the current output (i.e., missing dashes). I think > it should probably have dashes, but that should be fixed in a separate > patch. Agreed. -- 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