On 4/24/08, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > On Wed, 23 Apr 2008, Avery Pennarun wrote: > > What I really want is the equivalent of "dos2unix --recursive *.c *.txt > > etc" for all commits. > > I start to wonder if "git fast-export --all | my-intelligent-perl-script | > git fast-import" would not be a better solution here. > > All you would have to do is to detect when a blob begins, and how long it > is, and work with that. If your trees do not contain any binary files, it > should be trivial. Err, yes... as long as there are no binary files. I'm not so lucky, and life is a little more complex in that case. It also gives no easy way of selectively applying the blob filter based on filename, which is pretty important when you do have some binary files and you're trying to decide whether to run dos2unix. (In contrast, the *other* objection, which is that the same blob might have multiple filenames, doesn't bother me at all, since I'm sure I don't have any .txt files that were accidentally named .jpg at some point.) I agree that a working solution based on git-fast-export/git-fast-import should run faster than any of the other proposed solutions, but my version of Jeff's patch is quite fast and it's easy to compose simple command lines that "make simple things simple and hard things possible": git-filter-branch --blob-filter dos2unix HEAD git-filter-branch --blob-filter 'case "$path" in *.c) expand -8;; *) cat;; esac' HEAD It sure beats writing a perl script every time you want to do something. Jeff wrote: > 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 The problem is that doing an optimization on an index filter is kind of hard for a user to express, and each user will have to implement the caching logic by hand every time. Using --index-filter at all requires extremely high levels of shell and git knowledge. The fact that the blob transformation might "slightly depend on" the path is not actually very important; fundamentally we're still transforming blobs, not paths. We're just using the filename as a *hint* about what kind of transformation we need to do on that particular blob. I think the measure of a good idea here is how straightforward it is to express what you want on the command line, and --blob-filter makes it easy to express a certain class of filters. 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
