On Wed, Nov 22, 2017 at 11:01:22AM +0900, Junio C Hamano wrote:
> Torsten Bögershausen <[email protected]> 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.
