On 4/23/08, Junio C Hamano <gitster@xxxxxxxxx> wrote: > But once you start saying "even originally the same blob (i.e. identified > by one object name) can be rewritten into different result, depending on > where in the tree it appears", would it make sense to have blob filters to > begin with? > > Shouldn't that kind of of context sensitive (in the space dimension -- you > can introduce the context sensitivity in the time dimension by saying > there may even be cases where you would want to filter differently > depending on the path and which commit the blob appears, which is even > worse) filtering be best left to the tree or index filter? What I really want is the equivalent of "dos2unix --recursive *.c *.txt etc" for all commits. Theoretically, a .txt file might be renamed to a .jpg file, in which case funny things would happen with such a filter, depending which commit was seen first. I'm pretty confident that this will never happen to me, but it's a valid concern. Have fun, Avery -- 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
