Re: core.safecrlf warning is confusing[improvement suggestion?]
- From
Torsten Bögershausen <tboegi@web.de>
- Date
- Nov 22, 2017, 14:56 UTC
- Message-ID
- <20171122145632.GA22931@tor.lan>
- In-Reply-To
- <xmqqine3xea5.fsf@gitster.mtv.corp.google.com>
On Wed, Nov 22, 2017 at 11:01:22AM +0900, Junio C Hamano wrote:
Show 19 quoted lines
> 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-projectThat 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.
Show 18 quoted lines
> > 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.