On 27/07/2021 00:03, Chris Torek wrote:
On Mon, Jul 26, 2021 at 12:57 PM Martin <git@xxxxxxxxxx> wrote:
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.
