Re: mingw, windows, crlf/lf, and git

[Junio C Hamano <junkio@cox.net>]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> Btw, how would I implement this? If I really were energetic enough to 
> implement it, I would do:
>
>  (a) Add a flag to "git-ls-files" logic to add "type information" in 
>      front.
>
>      Not only do you want this *anyway* for other reasons, but for
>      binary/text, the thing you actually care most about is "git add", and 
>      it already basically just does "take this file pattern, feed it 
>      through git-ls-files, and add those files". So you'd get it basically 
>      for free.
>
>      It is also fairly easy to add at this stage, because you can simply 
>      look for all the places that work with "info/exclude" and 
>      ".gitignore", and you know that "Ahh, I need to teach these exact 
>      places to understand about attributes". So you'd add an 
>      "add_attributes_from_file()" function etc etc.
>
>      Quite straightforward. In fact, you might be able to use the 
>      gitignore parsing *as*is*, and just teach it about more flags that 
>      just "ignore": both in "struct dir_entry" and in "struct exclude".
>
>  (b) Teach the git-update-index logic about hashing text blobs.

I agree that we can assume editors can grok files with LF
end-of-line just fine and we would not need to do the reverse
conversion on checkout paths (e.g. "read-tree -u", "checkout-index").

Textual diff generation needs to learn the CRLF-to-LF conversion
in diff_populate_filespec(); this needs to be done even when the
caller wants size_only.

Oops.

Not so fast.  What's your plan for st_size?

>  (c) Profit!
>
> It really should be fairly straightforward. I'm sure it wouldn't be 
> *entirely* trivial, but I'm also fairly sure that somebody reasonably 
> competent could do it in a couple of days (with testing) if they were just 
> sufficiently motivated to get started.
>
> Anybody?

Not me.