On Wed, Dec 02, 2015 at 08:40:05AM -0800, Junio C Hamano wrote: > But for this particular one, I viewed the topic as adding a new > option as a shorter way for passing multiple -e <pattern> options on > the command line. When viewed that way, even if core.excludesfile > were multi-valued, I wouldn't have imagined that people would try to > use that mechanism for such a purpose--for one thing, the precedence > order is wrong for that purpose, isn't it? Good point. I didn't think about precedence at all. I perhaps shouldn't have brought up core.excludesfile as all. I only meant it as "you maybe can hack your way through to this without adding any code". I think a real option to do git-wide excludes would probably be more like: git --exclude-from=/path/to/file clean ... and that in turn would probably set GIT_EXCLUDE_FROM to a colon-separated list of paths (or similar) so that sub-processes would respect it, too. On the other hand, one could make the same argument about the existing "-e". You cannot do: git add --exclude='*.o' . right now. So maybe "clean" is really the only place where people care about such ad-hoc exclusion. Or maybe this an opportunity to add: git --exclude='*.o' clean I dunno. I cannot think of a time when I would have used any of those options myself. -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