Re: Files modified, even after: git reset --hard

On 27/07/2021 00:03, Chris Torek wrote:

On Mon, Jul 26, 2021 at 12:57 PM Martin [off-list ref] wrote:

quoted

Is it possible that those cheats also look at the "replaced" (rather
than the "replacement") commit(s)?

[1]: https://git-scm.com/docs/racy-git/en
[2]: https://web.archive.org/web/20101214222704/http://msdn.microsoft.com/en-us/library/14h5k7ff(v=vs.80).aspx

Thanks for the info. I still think there is something wrong.
So I made a simple testcase

https://github.com/User4martin/testrep.git
git fetch origin 'refs/replace/*:refs/replace/*'


All tested on linux. (Though git version 2.25.1)

git init test

FILE .gitattributes
foo -text

FILE foo
AAAAA

git add .gitattributes foo
git commit -m A

modify foo (real content modify)
add / commit -m B
modify foo (real content modify)
add / commit -m C

switch -d <A>
modify foo to be the same as commited to "C"
add / commit -m A2

git show
- get the old and new hash for the blob containing foo
git replace old new

Now commit A has the same content in foo as commit C
(we are currently at the detached commit A2)

git switch <C>
git status  // all fine

git switch <A>
git status
=> foo is modified
git diff
=> no diff


So I would say, it is not autorclf, or line endings in this case.

I do not know, if the above can be caused by "raciness".
But it appears to only(?) happens if a replace is in place.

So at this point my guess would be, that when the switch is done, at 
some point something looks at the original blob, even though it is meant 
to look at the replacement.