problem with BOINC repository and CR/LF

problem with BOINC repository and CR/LF

[Toralf Förster]

Hello,

I'm faced with this situation :
http://lists.ssl.berkeley.edu/mailman/private/boinc_alpha/2012-December/017371.html
and even a "git stash" doesn't help.

Now /me wonders whether that repository is just screwed up or whether I
do have with git.1.8.0.2 at an almost stable Gentoo linux a problem.
FWIW I already played (unsuccessful) with this too:


$ grep -B 3 crlf .gitconfig
        confirm = never

[core]
        autocrlf = true


-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Re: problem with BOINC repository and CR/LF

[Andrew Ardill]

On 17 December 2012 21:23, Toralf Förster <toralf.foerster@gmx.de> wrote:
> Hello,
>
> I'm faced with this situation :
> http://lists.ssl.berkeley.edu/mailman/private/boinc_alpha/2012-December/017371.html
> and even a "git stash" doesn't help.

Hi Toralf,

That list is private and not visible without an account. Can you
transcribe the relevant parts?

Regards,

Andrew Ardill

Re: problem with BOINC repository and CR/LF

[Toralf Förster]

On 12/17/2012 12:38 PM, Andrew Ardill wrote:
> On 17 December 2012 21:23, Toralf Förster <toralf.foerster@gmx.de> wrote:
>> Hello,
>>
>> I'm faced with this situation :
>> http://lists.ssl.berkeley.edu/mailman/private/boinc_alpha/2012-December/017371.html
>> and even a "git stash" doesn't help.
> 
> Hi Toralf,
> 
> That list is private and not visible without an account. Can you
> transcribe the relevant parts?
> 
> Regards,
> 
> Andrew Ardill
> 
Oh of course :


On 12/17/2012 12:03 AM, Gianfranco Costamagna wrote:
> So if you have further issues with boinc feel free to look in our debian
> git and feel free to download appropriate patches :-)
>
> Gianfranco
thx

Currently I'm struggling with a git problem of the boinc repository
itself and b/c I'm using git for the linux kernel tree w/o any problems
since eons /me wonders whether this is a BOINC-repository specific problem :


After doing the following sequence with git 1.8.0.2 :

$> git clone git://boinc.berkeley.edu/boinc.git
$> cd boinc
$> git checkout client_release_7.0.39
$> git checkout master
(sometimes I've to repeat this :
	$> git checkout client_release_7.0.39
	$> git checkout master
)
I'm faced with this situation :

$ git status
# On branch 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:   clientgui/AsyncRPC.cpp
#       modified:   clientgui/sg_BoincSimpleFrame.cpp
#
no changes added to commit (use "git add" and/or "git commit -a")

(sometimes only clientgui/sg_BoincSimpleFrame.cpp is mentioned)

Now these commands

$ git checkout -- clientgui/AsyncRPC.cpp
$ git checkout -- clientgui/sg_BoincSimpleFrame.cpp

doesn't help - the status is still the same (and ofc now I'm no longer
allowed to make a "git checkout" - due to un-commited changes).

Now I'm wondering where to start to investigate this issue ...

-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Re: problem with BOINC repository and CR/LF

[Andrew Ardill]

On 18 December 2012 03:01, Toralf Förster <toralf.foerster@gmx.de> wrote:
> On 12/17/2012 12:38 PM, Andrew Ardill wrote:
>> On 17 December 2012 21:23, Toralf Förster <toralf.foerster@gmx.de> wrote:
>>> Hello,
>>>
>>> I'm faced with this situation :
>>> http://lists.ssl.berkeley.edu/mailman/private/boinc_alpha/2012-December/017371.html
>>> and even a "git stash" doesn't help.
>>
>> Hi Toralf,
>>
>> That list is private and not visible without an account. Can you
>> transcribe the relevant parts?
>>
>> Regards,
>>
>> Andrew Ardill
>>
> Oh of course :
>
>
> On 12/17/2012 12:03 AM, Gianfranco Costamagna wrote:
>> So if you have further issues with boinc feel free to look in our debian
>> git and feel free to download appropriate patches :-)
>>
>> Gianfranco
> thx
>
> Currently I'm struggling with a git problem of the boinc repository
> itself and b/c I'm using git for the linux kernel tree w/o any problems
> since eons /me wonders whether this is a BOINC-repository specific problem :
>
>
> After doing the following sequence with git 1.8.0.2 :
>
> $> git clone git://boinc.berkeley.edu/boinc.git
> $> cd boinc
> $> git checkout client_release_7.0.39
> $> git checkout master
> (sometimes I've to repeat this :
>         $> git checkout client_release_7.0.39
>         $> git checkout master
> )
> I'm faced with this situation :
>
> $ git status
> # On branch 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:   clientgui/AsyncRPC.cpp
> #       modified:   clientgui/sg_BoincSimpleFrame.cpp
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> (sometimes only clientgui/sg_BoincSimpleFrame.cpp is mentioned)
>
> Now these commands
>
> $ git checkout -- clientgui/AsyncRPC.cpp
> $ git checkout -- clientgui/sg_BoincSimpleFrame.cpp
>
> doesn't help - the status is still the same (and ofc now I'm no longer
> allowed to make a "git checkout" - due to un-commited changes).
>
> Now I'm wondering where to start to investigate this issue ...

Hi Toralf,

That does look like a weird issue. What operating system are you on?

What happens if you do a hard reset to the branch?

What is the ouptut of git diff --cached ?

Regards,

Andrew Ardill

Re: problem with BOINC repository and CR/LF

[Toralf Förster]

On 12/18/2012 02:56 AM, Andrew Ardill wrote:
> On 18 December 2012 03:01, Toralf Förster <toralf.foerster@gmx.de> wrote:
>> On 12/17/2012 12:38 PM, Andrew Ardill wrote:
>>> On 17 December 2012 21:23, Toralf Förster <toralf.foerster@gmx.de> wrote:
>>>> Hello,
>>>>
>>>> I'm faced with this situation :
>>>> http://lists.ssl.berkeley.edu/mailman/private/boinc_alpha/2012-December/017371.html
>>>> and even a "git stash" doesn't help.
>>>
>>> Hi Toralf,
>>>
>>> That list is private and not visible without an account. Can you
>>> transcribe the relevant parts?
>>>
>>> Regards,
>>>
>>> Andrew Ardill
>>>
>> Oh of course :
>>
>>
>> On 12/17/2012 12:03 AM, Gianfranco Costamagna wrote:
>>> So if you have further issues with boinc feel free to look in our debian
>>> git and feel free to download appropriate patches :-)
>>>
>>> Gianfranco
>> thx
>>
>> Currently I'm struggling with a git problem of the boinc repository
>> itself and b/c I'm using git for the linux kernel tree w/o any problems
>> since eons /me wonders whether this is a BOINC-repository specific problem :
>>
>>
>> After doing the following sequence with git 1.8.0.2 :
>>
>> $> git clone git://boinc.berkeley.edu/boinc.git
>> $> cd boinc
>> $> git checkout client_release_7.0.39
>> $> git checkout master
>> (sometimes I've to repeat this :
>>         $> git checkout client_release_7.0.39
>>         $> git checkout master
>> )
>> I'm faced with this situation :
>>
>> $ git status
>> # On branch 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:   clientgui/AsyncRPC.cpp
>> #       modified:   clientgui/sg_BoincSimpleFrame.cpp
>> #
>> no changes added to commit (use "git add" and/or "git commit -a")
>>
>> (sometimes only clientgui/sg_BoincSimpleFrame.cpp is mentioned)
>>
>> Now these commands
>>
>> $ git checkout -- clientgui/AsyncRPC.cpp
>> $ git checkout -- clientgui/sg_BoincSimpleFrame.cpp
>>
>> doesn't help - the status is still the same (and ofc now I'm no longer
>> allowed to make a "git checkout" - due to un-commited changes).
>>
>> Now I'm wondering where to start to investigate this issue ...
> 
> Hi Toralf,
> 
> That does look like a weird issue. What operating system are you on?

I'm running a stable Gentoo Linux x86, 32bit with gcc 4.6.3 and current
stable kernel 3.6.1x and 3.7.1, file system is ext4 at an external USB
2.0 drive.

FWIW from the boinc maintainer I know that all tags till 7.0.3X are
imported from svn.

I upgraded to git 1.8.0.2 from 1.7.8.6 - situation is the same. The
emerge gave :

failed test(s): t3600 t7508

fixed   0
success 8342
failed  8
broken  56
total   8528

Ok, now answering your other questions:


$> git stash
warning: CRLF will be replaced by LF in clientgui/AsyncRPC.cpp.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in clientgui/sg_BoincSimpleFrame.cpp.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in clientgui/AsyncRPC.cpp.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in clientgui/sg_BoincSimpleFrame.cpp.
The file will have its original line endings in your working directory.
Saved working directory and index state WIP on master: 4a296dc - client
simulator: fix build errors
HEAD is now at 4a296dc - client simulator: fix build errors

After that the situation is unchanged.

> What happens if you do a hard reset to the branch?

$> git reset --hard HEAD~1

not better.


> What is the ouptut of git diff --cached ?

The output is empty but "git status" shows still modified files.



FWIW there's a related issue I'm wondering about which might help:

$> git clone git://boinc.berkeley.edu/boinc.git
$> tar -cpf boinc.tar boinc/
$> rm -rf boinc/
$> tar -xpf boinc.tar
$> cd boinc/
$> git status
# On branch 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:   client/win/boinc_log.h
#       modified:   client/win/boinc_log.rc
#       modified:   clientctrl/boincsvcctrl.cpp
#       modified:   clientctrl/boincsvcctrl.h
#       modified:   clientctrl/boincsvcctrl.rc
#       modified:   clientgui/AsyncRPC.cpp
#       modified:   clientgui/DlgEventLog.cpp
#       modified:   clientgui/DlgEventLog.h
#       modified:   clientgui/DlgEventLogListCtrl.cpp
#       modified:   clientgui/DlgEventLogListCtrl.h
#       modified:   clientgui/DlgExitMessage.h
#       modified:   clientgui/DlgItemProperties.h
#       modified:   clientgui/TermsOfUsePage.cpp
#       modified:   clientgui/TermsOfUsePage.h
#       modified:   clientgui/ViewNotices.cpp
#       modified:   clientgui/ViewNotices.h
#       modified:   clientgui/sg_BoincSimpleFrame.cpp
#       modified:   clientscr/boinc_ss_opengl.h
#       modified:   clientscr/boinc_ss_opengl.rc
#       modified:   clientscr/screensaver.cpp
#       modified:   clienttray/boinc_tray.h
#       modified:   clienttray/boinc_tray.rc
#       modified:   clienttray/tray_win.cpp
#       modified:   clienttray/tray_win.h
#       modified:   coprocs/NVIDIA/include/nvapi.h
#
no changes added to commit (use "git add" and/or "git commit -a")
$> git diff --cached
$>



Meaning, w/o any other interaction a tar'ed archive has modified files -
and the diff is empty...

-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Re: problem with BOINC repository and CR/LF

[Toralf Förster]

On 12/18/2012 10:55 AM, Toralf Förster wrote:
> failed test(s): t3600 t7508
> 
> fixed   0
> success 8342
> failed  8
> broken  56
> total   8528
> 

ick forgot these :

n22 /usr/portage/dev-vcs/git # grep -i "^not ok" /tmp/git.log | grep -v TODO
not ok - 15 Test that "git rm -f" fails if its rm fails
not ok - 16 When the rm in "git rm -f" fails, it should not remove the file from the index
not ok - 20 Re-add foo and baz
not ok - 21 Modify foo -- rm should refuse
not ok - 22 Modified foo -- rm -f should work
not ok - 23 Re-add foo and baz for HEAD tests
not ok - 24 foo is different in index from HEAD -- rm should refuse
not ok - 55 status succeeds in a read-only repository

-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Re: problem with BOINC repository and CR/LF

[Torsten Bögershausen]

On 18.12.12 10:55, Toralf Förster wrote:
> On 12/18/2012 02:56 AM, Andrew Ardill wrote:
>> On 18 December 2012 03:01, Toralf Förster <toralf.foerster@gmx.de> wrote:
>>> On 12/17/2012 12:38 PM, Andrew Ardill wrote:
>>>> On 17 December 2012 21:23, Toralf Förster <toralf.foerster@gmx.de> wrote:
>>>>> Hello,
>>>>>
>>>>> I'm faced with this situation :
>>>>> http://lists.ssl.berkeley.edu/mailman/private/boinc_alpha/2012-December/017371.html
>>>>> and even a "git stash" doesn't help.
>>>>
>>>> Hi Toralf,
>>>>
>>>> That list is private and not visible without an account. Can you
>>>> transcribe the relevant parts?
>>>>
>>>> Regards,
>>>>
>>>> Andrew Ardill
>>>>
>>> Oh of course :
>>>
>>>
>>> On 12/17/2012 12:03 AM, Gianfranco Costamagna wrote:
>>>> So if you have further issues with boinc feel free to look in our debian
>>>> git and feel free to download appropriate patches :-)
>>>>
>>>> Gianfranco
>>> thx
>>>
>>> Currently I'm struggling with a git problem of the boinc repository
>>> itself and b/c I'm using git for the linux kernel tree w/o any problems
>>> since eons /me wonders whether this is a BOINC-repository specific problem :
>>>
>>>
>>> After doing the following sequence with git 1.8.0.2 :
>>>
>>> $> git clone git://boinc.berkeley.edu/boinc.git
>>> $> cd boinc
>>> $> git checkout client_release_7.0.39
>>> $> git checkout master
>>> (sometimes I've to repeat this :
>>>         $> git checkout client_release_7.0.39
>>>         $> git checkout master
>>> )
>>> I'm faced with this situation :
>>>
>>> $ git status
>>> # On branch 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:   clientgui/AsyncRPC.cpp
>>> #       modified:   clientgui/sg_BoincSimpleFrame.cpp
>>> #
>>> no changes added to commit (use "git add" and/or "git commit -a")
>>>
>>> (sometimes only clientgui/sg_BoincSimpleFrame.cpp is mentioned)
>>>
>>> Now these commands
>>>
>>> $ git checkout -- clientgui/AsyncRPC.cpp
>>> $ git checkout -- clientgui/sg_BoincSimpleFrame.cpp
>>>
>>> doesn't help - the status is still the same (and ofc now I'm no longer
>>> allowed to make a "git checkout" - due to un-commited changes).
>>>
>>> Now I'm wondering where to start to investigate this issue ...
>>
>> Hi Toralf,
>>
>> That does look like a weird issue. What operating system are you on?
> 
> I'm running a stable Gentoo Linux x86, 32bit with gcc 4.6.3 and current
> stable kernel 3.6.1x and 3.7.1, file system is ext4 at an external USB
> 2.0 drive.
> 
> FWIW from the boinc maintainer I know that all tags till 7.0.3X are
> imported from svn.
> 
> I upgraded to git 1.8.0.2 from 1.7.8.6 - situation is the same. The
> emerge gave :
> 
> failed test(s): t3600 t7508
> 
> fixed   0
> success 8342
> failed  8
> broken  56
> total   8528
> 
> Ok, now answering your other questions:
> 
> 
> $> git stash
> warning: CRLF will be replaced by LF in clientgui/AsyncRPC.cpp.
> The file will have its original line endings in your working directory.
> warning: CRLF will be replaced by LF in clientgui/sg_BoincSimpleFrame.cpp.
> The file will have its original line endings in your working directory.
> warning: CRLF will be replaced by LF in clientgui/AsyncRPC.cpp.
> The file will have its original line endings in your working directory.
> warning: CRLF will be replaced by LF in clientgui/sg_BoincSimpleFrame.cpp.
> The file will have its original line endings in your working directory.
> Saved working directory and index state WIP on master: 4a296dc - client
> simulator: fix build errors
> HEAD is now at 4a296dc - client simulator: fix build errors
> 
> After that the situation is unchanged.
> 
>> What happens if you do a hard reset to the branch?
> 
> $> git reset --hard HEAD~1
> 
> not better.
> 
> 
>> What is the ouptut of git diff --cached ?
> 
> The output is empty but "git status" shows still modified files.
> 
> 
> 
> FWIW there's a related issue I'm wondering about which might help:
> 
> $> git clone git://boinc.berkeley.edu/boinc.git
> $> tar -cpf boinc.tar boinc/
> $> rm -rf boinc/
> $> tar -xpf boinc.tar
> $> cd boinc/
> $> git status
> # On branch 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:   client/win/boinc_log.h
> #       modified:   client/win/boinc_log.rc
> #       modified:   clientctrl/boincsvcctrl.cpp
> #       modified:   clientctrl/boincsvcctrl.h
> #       modified:   clientctrl/boincsvcctrl.rc
> #       modified:   clientgui/AsyncRPC.cpp
> #       modified:   clientgui/DlgEventLog.cpp
> #       modified:   clientgui/DlgEventLog.h
> #       modified:   clientgui/DlgEventLogListCtrl.cpp
> #       modified:   clientgui/DlgEventLogListCtrl.h
> #       modified:   clientgui/DlgExitMessage.h
> #       modified:   clientgui/DlgItemProperties.h
> #       modified:   clientgui/TermsOfUsePage.cpp
> #       modified:   clientgui/TermsOfUsePage.h
> #       modified:   clientgui/ViewNotices.cpp
> #       modified:   clientgui/ViewNotices.h
> #       modified:   clientgui/sg_BoincSimpleFrame.cpp
> #       modified:   clientscr/boinc_ss_opengl.h
> #       modified:   clientscr/boinc_ss_opengl.rc
> #       modified:   clientscr/screensaver.cpp
> #       modified:   clienttray/boinc_tray.h
> #       modified:   clienttray/boinc_tray.rc
> #       modified:   clienttray/tray_win.cpp
> #       modified:   clienttray/tray_win.h
> #       modified:   coprocs/NVIDIA/include/nvapi.h
> #
> no changes added to commit (use "git add" and/or "git commit -a")
> $> git diff --cached
> $>
> 
> 
> 
> Meaning, w/o any other interaction a tar'ed archive has modified files -
> and the diff is empty...
> 
Hej,

I could re-produce the problem here:
git version 1.8.0.197.g5a90748
Mac OS X (that what I had at hands fastest)


After doing 
git checkout 5db4a05b5c8f9c420fc418727cafbb58e6051f1e
(same as master ?)
We see that 
clientgui/AsyncRPC.cpp
is full of CRLF and as it seems only CRLF, no single LF.

The file is classified as text:
$git check-attr text  clientgui/AsyncRPC.cpp
$clientgui/AsyncRPC.cpp: text: set
(And we can see this in .gitattributes as well)

(And there are more files affected, but I will only look at one of them)

If we remove the text attribute like this:
$mv .gitattributes .gitattributes.sav
we see

$git status
deleted:    .gitattributes
#       modified:   clientgui/sg_BoincSimpleFrame.cpp


If we dig into the file:
$git ls-files -s clientgui/AsyncRPC.cpp
100644 6832333ad133181986ada54fe0229b45a30c614a 0       clientgui/AsyncRPC.cpp

We see that it is recorded under 6832333ad1
And if we look into it:
$git show  6832333 | od -c
[snip]
we can see that the file has CRLF in the repo.

So my conclusion is:
The file has CRLF in the repo, but should have LF.
This is not a good thing, and the files need to be normalized.

A very good instruction how to do this, is found here:
http://kernel.org/pub/software/scm/git/docs/gitattributes.html
(You may want to search for "End-of-line conversion" or "core.autocrlf")

HTH
/Torsten


 

Re: problem with BOINC repository and CR/LF

[Jeff King]

On Tue, Dec 18, 2012 at 01:15:30PM +0100, Torsten Bögershausen wrote:

> I could re-produce the problem here:
> git version 1.8.0.197.g5a90748
> Mac OS X (that what I had at hands fastest)

I could reproduce it, too, on Linux.

The reason it does not always happen is that git will not re-examine the
file content unless the timestamp on the file is older than what's in
the index. So it is a race condition for git to see whether the file is
stat-dirty.

But you can make sure all files are stat-dirty by just resetting the
index:

  $ git clone git://boinc.berkeley.edu/boinc.git
  $ rm .git/index
  $ git reset

which shows the complete list of files with LF/CRLF normalization
issues.

> So my conclusion is:
> The file has CRLF in the repo, but should have LF.
> This is not a good thing, and the files need to be normalized.

Yes, exactly. The project has told git via .gitattributes that certain
files should have particular line endings in the repository, but that is
not the case with the current versions. Doing:

  $ git commit -a -m 'normalize line endings according to gitattributes'

on top of the commands above would fix it (for that commit and onwards,
anyway).

-Peff

Re: problem with BOINC repository and CR/LF

[Toralf Förster]

On 12/18/2012 01:15 PM, Torsten Bögershausen wrote:
> HTH
> /Torsten

Thx Torsten - I forwarded this answer (and all the other answers) to the
boinc alpha mailing list
- there's now a discussion about that.



-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Re: problem with BOINC repository and CR/LF

[Toralf Förster]

On 12/18/2012 05:41 PM, Jeff King wrote:
> I could reproduce it, too, on Linux.
> 
> The reason it does not always happen is that git will not re-examine the
> file content unless the timestamp on the file is older than what's in
> the index. So it is a race condition for git to see whether the file is
> stat-dirty.
> 

Ah - /me was wondering why sometimes (but rarely) I could not exactly
reproduce the problem and was really wondering if the underlying file
system (ext4) would give an extra layer of trouble or not.

Thx for that explanation.


-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Re: problem with BOINC repository and CR/LF

[Toralf Förster]

On 12/18/2012 05:41 PM, Jeff King wrote:
> I could reproduce it, too, on Linux.
> 
> The reason it does not always happen is that git will not re-examine the
> file content unless the timestamp on the file is older than what's in
> the index. So it is a race condition for git to see whether the file is
> stat-dirty.

/me still wonders whether this race condition is a feature or an issue
in GIT - b/c it means that 2 different people cloning the same
repository get different results.


> 
> -Peff
> 


-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Re: problem with BOINC repository and CR/LF

[Dmitry Potapov]

On Sat, Dec 22, 2012 at 4:31 PM, Toralf Förster <toralf.foerster@gmx.de> wrote:
>
> /me still wonders whether this race condition is a feature or an issue
> in GIT - b/c it means that 2 different people cloning the same
> repository get different results.

The problem is that Git assumes that conversion from git to the worktree
and back produces the same result. Unfortunately, this assumption is not
enforced anywhere and when it is broken by editing .gitattributes, it may
be difficult to notice that immediately unless you do that trick with
removing the index and "git reset". Perhaps, it would be better if
git considered that timestamps on all files changed if .gitattributes
is changed, so it would check all files for consistence, then anyone
who edits .gitattributes will be forced to fix the file ending to be
consistent.

Anyway, when this underlying assumption is broken, it is easy to get
that race, because git checks only those files for modification that
have its timestamp equal or newer than the index. (The equal timestamp
are inspected for modification, because the timestamp resolution can
be 1 second on some systems.) When you check out some version, some
of files are going to have an older timestamp than the index (and thus
they are not inspected for modification) but those that have the same
timestamp as the index are inspected for modification.


Dmitry

Re: problem with BOINC repository and CR/LF

[Junio C Hamano]

Toralf Förster <toralf.foerster@gmx.de> writes:

> On 12/18/2012 05:41 PM, Jeff King wrote:
>> I could reproduce it, too, on Linux.
>> 
>> The reason it does not always happen is that git will not re-examine the
>> file content unless the timestamp on the file is older than what's in
>> the index. So it is a race condition for git to see whether the file is
>> stat-dirty.
>
> /me still wonders whether this race condition is a feature or an issue
> in GIT - b/c it means that 2 different people cloning the same
> repository get different results.

The primary point of Peff's demonstration was to show that you told
your repository to lie to Git, I think.  It promised that the
contents in the repository was with certain line endings when they
are not.  At that point Git can do whatever happens when it trusts
its behaviour on that broken promise.

When the timestamp is set one way, Git happened to be extra careful
for other reasons---Git is not in the business of suspecting that
the user lied and double checking by wasting cycles [*1*]---and that
extra check that does not have anything to do with the end-of-line
conversion found that it was lied and noticed differences.

That is neither a feature nor a bug.

[Footnote]

*1* This extra carefulness is to handle the case where *filesystems*
lie to Git.  The user cannot do anything to make the filesystem not
to lie, so we try to be extra careful and examine the contents even
when the stat information (incorrectly) says that the file is not
modified.  Also luckily this happens only to minority of the paths
(i.e. you do "git add" and then replace the file with different
contents of the same length within the same timestamp granularity,
or something like that), so we can afford to.