On Wed, Apr 23, 2008 at 04:01:10PM -0700, Junio C Hamano 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?
Yes, that was my original reasoning. But I think the problem then is
that the blob filter isn't terribly useful. IOW, it is not really a
separate filter, but rather an optimizing pattern for an index filter,
so maybe calling it a blob filter is the wrong approach, and it would be
better as a short perl script in contrib/filter-branch. Then you could
call:
git filter-branch --index-filter '
/path/to/git/contrib/filter-branch/dos2unix \
"*.txt" "*.c"
'
-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
