mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: "Torsten Bögershausen" <>
Cc: Vladimir Nikishkin <>,
Subject: Re: core.safecrlf warning is confusing[improvement suggestion?]
Date: Wed, 22 Nov 2017 11:01:22 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20171121161824.GA13548@tor.lan> ("Torsten Bögershausen"'s message of "Tue, 21 Nov 2017 17:18:24 +0100")

Torsten Bögershausen <> 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'

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.

  reply	other threads:[~2017-11-22  2:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-21  5:18 core.safecrlf warning is confusing[improvement suggestion?] Vladimir Nikishkin
2017-11-21  5:44 ` Junio C Hamano
2017-11-21  5:49 ` Junio C Hamano
2017-11-21 16:18 ` Torsten Bögershausen
2017-11-22  2:01   ` Junio C Hamano [this message]
2017-11-22 14:56     ` Torsten Bögershausen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).