On Thu, Jun 12, 2008 at 08:01:45PM -0700, Junio C Hamano wrote: > makes some sense. Being able to produce an unusable patch by saying > > $ git format-patch --stat old.. > > at the first glance is of quite dubious value, but even that would make > sense as a good input source for "commit log automailer". > > I think I know where Jon is coming from and where he wants to go. While I > am somewhat sympathetic to the cause of adding some warning or safety > valve to prevent nonsense option combinations from being given, I am not > sure we can draw a line to classify options into black and white. I am against a safety valve here. For example, I have the following alias: format-patch --pretty=format:%s%n%n%b which obviously does not generate a valid email, but which I use for pulling "how about this?" patches directly into existing emails (otherwise, I have to delete the header cruft myself). Yes, I _could_ do this with git-log, but format-patch has slightly different command line semantics. And it most clearly expresses what I want: the patch submission format, but with the header bits pretty-printed differently. My point being that this flexibility _is_ useful, and I am not sure it is worth removing it in favor of people who get confused about why git format-patch --pretty=format:%s%n%n%b origin | git send-email doesn't work. -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
