threads / discuss / 32373

problem with BOINC repository and CR/LF

Subject: problem with BOINC repository and CR/LF

## tl;dr

13 messages between Dec 17, 2012 and Dec 22, 2012.

replies: 12people: 6as markdown or json

Toralf Förster· Dec 17, 2012, 10:23 UTC · lore
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
Andrew Ardill· Dec 17, 2012, 11:38 UTC · re: Toralf Förster · lore

Re: problem with BOINC repository and CR/LF

On 17 December 2012 21:23, Toralf Förster <toralf.foerster@gmx.de> wrote:
Show 5 quoted lines
> 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
Toralf Förster· Dec 17, 2012, 16:01 UTC · re: Andrew Ardill · lore

Re: problem with BOINC repository and CR/LF

On 12/17/2012 12:38 PM, Andrew Ardill wrote:
Show 16 quoted lines
> 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
Andrew Ardill· Dec 18, 2012, 01:56 UTC · re: Toralf Förster · lore

Re: problem with BOINC repository and CR/LF

On 18 December 2012 03:01, Toralf Förster <toralf.foerster@gmx.de> wrote:
Show 67 quoted lines
> 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
Toralf Förster· Dec 18, 2012, 09:55 UTC · re: Andrew Ardill · lore

Re: problem with BOINC repository and CR/LF

On 12/18/2012 02:56 AM, Andrew Ardill wrote:
Show 72 quoted lines
> 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
Toralf Förster· Dec 18, 2012, 09:58 UTC · re: Toralf Förster · lore

Re: problem with BOINC repository and CR/LF

On 12/18/2012 10:55 AM, Toralf Förster wrote:
Show 8 quoted lines
> 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
Torsten Bögershausen· Dec 18, 2012, 12:15 UTC · re: Toralf Förster · lore

Re: problem with BOINC repository and CR/LF

On 18.12.12 10:55, Toralf Förster wrote:
Show 172 quoted lines
> 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

 
Jeff King· Dec 18, 2012, 16:41 UTC · re: Torsten Bögershausen · lore

Re: problem with BOINC repository and CR/LF

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
Toralf Förster· Dec 19, 2012, 10:44 UTC · re: Jeff King · lore

Re: problem with BOINC repository and CR/LF

On 12/18/2012 05:41 PM, Jeff King wrote:
Show 7 quoted lines
> 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
Toralf Förster· Dec 22, 2012, 12:31 UTC · re: Jeff King · lore

Re: problem with BOINC repository and CR/LF

On 12/18/2012 05:41 PM, Jeff King wrote:
Show 6 quoted lines
> 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
Dmitry Potapov· Dec 22, 2012, 18:54 UTC · re: Toralf Förster · lore

Re: problem with BOINC repository and CR/LF

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
Junio C Hamano· Dec 22, 2012, 19:17 UTC · re: Toralf Förster · lore

Re: problem with BOINC repository and CR/LF

Toralf Förster <toralf.foerster@gmx.de> writes:
Show 11 quoted lines
> 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.

Toralf Förster· Dec 19, 2012, 10:43 UTC · re: Torsten Bögershausen · lore

Re: problem with BOINC repository and CR/LF

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

← back to recent threads