On Sat, Oct 6, 2012 at 1:48 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > >> +Unlike `.gitignore`, negative patterns are not supported. >> +Patterns that match directories are also not supported. > > Is "are not supported" the right phrasing? > > I think it makes perfect sense not to forbid "!path attr1", because > it is unclear what it means (e.g. "path -attr1" vs "path !attr1"). > So I would say "Negative patterns are forbidden as they do not make > any sense". !path/sub/ alone does not mean anything. It must be used together with a positive pattern to define the set of paths the same attribute assignment statement applies to. This makes sense (attr, -attr1 or !attr1 are all OK): *.c attr1 !foo.c attr1 But this does not (actually "!foo.c" line has no effects because of different attribute assignments): *.c attr1 !foo.c attr2 It could be even more confusing in multiple attribute manipulation: *.c attr1 *.h -attr2 !foo.[ch] attr1 -attr2 So "not supported" and "forbidden" are equally OK. I just want to raise a point that it has some use before we go for "forbidden". > Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes: > >> On Sat, Oct 6, 2012 at 12:36 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>>> Or the user might think "path/ attr1" sets attr1 for all files under >>>> "path/" because it does not make sense to attach attributes to a >>>> directory in git. >>> >>> ... >>> >>> We may not have a need to assign a real attribute to a directory >>> right now, because nothing in Git asks for an attribute for a >>> directory. But that does not necessarily mean we would never need a >>> way to give an attribute to a directory but not to its contents. >> >> Exactly why we should not make "path/ attr" no-op. If we want to make >> it meaningful some day in future, I don't think we want those no-ops >> lay around and suddenly cause changes in behavior with a new version >> of git. > > I do not think you understood. "path/ attr" is a no-op from the > point of view of the *users* of the current versions of Git. It is > perfectly fine to accept and apply attr to "path/"; no codepath in > Git should be asking about path/ anyway, so it ends up to be a > no-op. You shouldn't be erroring out at the syntactic level, i.e. > when these lines are parsed. My objection is no-op lines are timed bombs. But users can already do "dir attr" (no slashes), which is no-op. So yeah, no-op is fine. -- Duy -- 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