Re: Git on Windows, CRLF issues

["Avery Pennarun" <apenwarr@gmail.com>]

On 4/24/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> 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