Jeff King <peff@xxxxxxxx> writes: > The correct fix is either: > > - the blob cache needs to take into account sha1 _and_ path > > - the cache lookup needs to be _inside_ the path filter. In that case > you would either have to support it in the script (e.g., > --blob-ignore jpg), or you could make the caching an optional part > of the blob filter (the way you can call 'map' explicitly from your > filters). 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? -- 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
