On Fri, Dec 16, 2011 at 11:05:27PM +0100, Johannes Sixt wrote: > Am 16.12.2011 20:21, schrieb Jeff King: > > I'm not clear from what you wrote on whether you were saying it is > > simply sub-optimal, or whether on balance it is way worse than the > > default funcname matching. > > I'm saying the latter. Okay, we're talking "only" about hunk headers. > But when you are reviewing patches, they are *extremely* useful and a > time-saver; when they are wrong or not present, they are exactly the > opposite. Right. I don't think it is worth arguing "well, it's only funcname headers". Because that same argument applies to both the advantages (i.e., hopefully with the patch we are generating better funcname headers) and disadvantage (i.e., it seems that we might be generating worse funcname headers). So it is really a question of "how good" or "how bad" for each style. > Sure I have. What I didn't say (sorry for that!), but wanted to hint at > is that this is to experiment with a pattern in order to ultimately > improve the built-in pattern. The topic came up just the other day, and > I took Thomas Rast's suggestion to experiment with a simplified pattern: > > http://thread.gmane.org/gmane.comp.version-control.git/186355/focus=186439 > > But as is, the built-in pattern misses way too many anchor points in C++ > code. Yeah, I can certainly agree that the patterns could be better. Maybe we should just table the extension mapping for now, then, and see if the patterns improve? Or maybe just drop the C ones (and probably the objc one based on other parts of the thread) and do the rest? -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