Re: core.safecrlf warning is confusing[improvement suggestion?]

["Torsten Bögershausen" <tboegi@web.de>]

On Wed, Nov 22, 2017 at 11:01:22AM +0900, Junio C Hamano wrote:
> Torsten Bögershausen <tboegi@web.de> writes:
> 
> >> I want to have LF line endings in the repository and CRLF endings in
> >> the working copy. (Because I use windows-exclusive tools to develop.)
> >
> > Side note: If you ever want to push your repository somewhere,
> > it would be good practice to have a .gitattributes file:
> > ...
> 
> Now we got your attention ;-)
> 
> What would be the BCP we would give if somebody has just a tarball
> without .git that has LF endings?
> 
>     $ git init a-project
>     $ cd a-project
>     $ tar xf ../a-project.tar
>     $ git add .
>     $ git commit -m 'Initial import'

There is room for small improvements:
     $ cd /tmp
     $ git init a-project
     $ cd a-project
     $ tar xf ../a-project.tar
     $ git -c core.autocrlf=false add .
     $ git commit -m 'Initial import'
     # Make up your mind: is it truly cross-platform ?
       $ echo "* text=auto" >.gitattributes
       # E.g. if you have shell scripts:
       $ echo "*.sh text eol=lf" >>.gitattributes
       # E.g. if you are a git developer:
       $ echo "/GIT-VERSION-GEN eol=lf" >>.gitattributes   
      # Or, is it e.g. a project where a tool needs some line endings
      # visual studio is one example, there are many others:
       $ echo "* -text" >.gitattributes
      # in any case, we need to commit: 
      $ git add .gitattributes && git commit -m "Add .gitattributes"

# Now we have the repo. I we don't want the hammer, simply clone it:
     $ cd $HOME
     $ git clone /tmp/a-project

That should work for project small enough not to fill the disk.
And other adjustments may be needed to the .gitattributes file.
A final check with
$ git ls-files --eol
may give inspiration.

> 
> would achieve one half of the original wish (i.e. "I want to end up
> with repository data in LF eol"); disabling the "safe crlf" before
> running that "git add ." step may also not be a bad idea, because it
> reduces the number of things that can get in the way by one.
> 
> But the above also leaves the "working tree" files in LF eol
> (i.e. it goes against "I want to work with CRLF in my working
> tree").  What would be our recommendation?
> 
> One big-hammer way I can think of is
> 
>     $ git rm -f .
>     $ git reset --hard
> 
> and that actually may be a good enough solution, given that you'd be
> doing this just once at the beginning of "your" project that starts
> from an inherited code drop.