From: "Torsten Bögershausen" <tboegi@web.de>
To: "Yue Lin Ho" <yuelinho777@gmail.com>,
git@vger.kernel.org, "Torsten Bögershausen" <tboegi@web.de>
Subject: Re: The different EOL behavior between libgit2-based software and official Git
Date: Thu, 19 Jun 2014 08:39:29 +0200 [thread overview]
Message-ID: <53A285A1.3090804@web.de> (raw)
In-Reply-To: <1403146778624-7613670.post@n2.nabble.com>
On 06/19/2014 04:59 AM, Yue Lin Ho wrote:
> Hi:
>
> ^_^
>
> I did some test on the EOL behavior between official git and libgit2-based
> software(TortoiseGit).
> Then, I got that they have different EOL behavior.
>
> The blob stored in repository is a text file with mixed EOLs.
> Even set core.autocrlf = true, official git checkout the file as it is(means
> still *mixed EOLs* there).
> But, libgit2 checkout it with *All CRLF EOLs*.
>
> * The steps:
> * set core.autocrlf = false
> * add file with mixed EOLs
> * set core.autocrlf = true
> * delete that file in the working tree
> * checkout that file
> * examine the EOL
>
> If you are interested in this, you might take a look at my testing
> repository on GitHub.
> (https://github.com/YueLinHo/TestAutoCrlf)
>
> Thank you.
>
> Yue Lin Ho
(I send a similar mail to msysgit, I'm not sure if this came trough)
Sorry being late, I don't think there is something wrong with Git.
The core.autocrlf is the "old" crlf handling, which has been in Git for
a long time.
If you exactly know what you are doing, know exactly
which tools are doing what, convince everybody who pulls or pushes to
that repo to use
the same local config then it may be useful.
In short: I would strongly recommend to use gitattributes, please see
below.
tb@msygit ~/temp
$ git clone https://github.com/YueLinHo/TestAutoCrlf.git
Cloning into 'TestAutoCrlf'...
[snip]
$ cd TestAutoCrlf/
tb@msygit ~/temp/TestAutoCrlf (master)
$ ls
CRLF.txt LF.txt MIX-more_CRLF.txt MIX-more_LF.txt Readme.md
###### Check how the file looks like:
$ od -c MIX-more_LF.txt
0000000 L i n e 1 \n l i n e ( 2 ) \r
0000020 \n l i n e 3 . \n t h i s i s
0000040 l i n e 4 \n l i n e
0000060 N o . 5 \n L i n e N u m b e
0000100 r 6 \n
0000104
####### The file has one CRLF, the rest is LF, exactly how it had been
####### commited. So this is what we expect. Or do I miss something ?
####### Tell Git that MIX-more_LF.txt is a text file:
$ echo MIX-more_LF.txt text >.gitattributes
####### Verify that MIX-more_LF.txt is text, all other files
####### are "binary" (or "-text" in Git language)
$ git check-attr text *
CRLF.txt: text: unspecified
LF.txt: text: unspecified
MIX-more_CRLF.txt: text: unspecified
MIX-more_LF.txt: text: set
Readme.md: text: unspecified
####### Now ask Git to normalize the line endings in the working tree
$ rm MIX-more_LF.txt
tb@msygit ~/temp/TestAutoCrlf (master)
$ git checkout MIX-more_LF.txt
########## Check what we got:
tb@msygit ~/temp/TestAutoCrlf (master)
$ od -c MIX-more_LF.txt
0000000 L i n e 1 \r \n l i n e ( 2 )
0000020 \r \n l i n e 3 . \r \n t h i s
0000040 i s l i n e 4 \r \n l i n
0000060 e N o . 5 \r \n L i n e N
0000100 u m b e r 6 \r \n
0000111
######### (This is under Windows, under Linux I would expect only LF)
######### See core.eol for for information
##########
########## Now we need to normalize the file in the repo,
########## All line endings should be LF, otherwise Git
########## things the file is modified:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working
directory)
modified: MIX-more_LF.txt
Untracked files:
(use "git add <file>..." to include in what will be committed)
.gitattributes
no changes added to commit (use "git add" and/or "git commit -a")
###############
############### Do the normalization:
tb@msygit ~/temp/TestAutoCrlf (master)
$ git add MIX-more_LF.txt .gitattributes
tb@msygit ~/temp/TestAutoCrlf (master)
$ git commit -m "MIX-more_LF.txt is text"
[master 200d874] MIX-more_LF.txt is text
Committer: unknown <tb@msysgit>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:
git config --global user.name "Your Name"
git config --global user.email you@example.com
After doing this, you may fix the identity used for this commit with:
git commit --amend --reset-author
2 files changed, 2 insertions(+), 1 deletion(-)
create mode 100644 .gitattributes
tb@msygit ~/temp/TestAutoCrlf (master)
$
######## From now on, MIX-more_LF.txt is treated as text by Git,
######## and get CRLF under Windows.
######## I think there is nothing wrong with Git here.
######## If libgit2 does something different, we need to ask
######## the libgit2 project, which is independent from Git
next prev parent reply other threads:[~2014-06-19 6:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-19 2:59 The different EOL behavior between libgit2-based software and official Git Yue Lin Ho
2014-06-19 6:39 ` Torsten Bögershausen [this message]
2014-06-19 7:25 ` Yue Lin Ho
2014-06-20 6:56 ` Torsten Bögershausen
2014-06-20 8:30 ` Yue Lin Ho
2014-06-20 10:33 ` [msysGit] " Torsten Bögershausen
2014-06-20 16:33 ` Junio C Hamano
2014-06-22 6:46 ` [msysGit] " Torsten Bögershausen
2014-06-23 17:29 ` Junio C Hamano
2014-06-20 8:44 ` Yue Lin Ho
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53A285A1.3090804@web.de \
--to=tboegi@web.de \
--cc=git@vger.kernel.org \
--cc=yuelinho777@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
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 NNTP newsgroup(s).