On 26/07/2021 02:33, Chris Torek wrote:
On Sun, Jul 25, 2021 at 11:43 AM Martin <git@xxxxxxxxxx> wrote:
[Files show up as every-line-modified]
[and] git replace has a weird effect.
Ok, it seem that
git switch
simple did not update the file.
...
Let's suppose, just for convenience for now, that the files in the
repository right now actually do have CRLF line endings.
Let's suppose further that you ask that Git ensure that your
*working tree* copies of each file contain CRLF line endings.
Yes, I accept that decision.
I figured that is the reason why they show modified.
Not a problem. Until I am in the middle of a rebase, and i cannot run
(after a conflict)
git rebase --continue
The modified files are not part of the original series of commits. they
are just random files from somewhere else in the tree.
I can not reset/restore them.
So I must now "git add" files entirely unrelated to continue rebasing.
Well or apparently change my config for the duration of the rebase.
As for "git replace", you've figured the rest out already: if
you use git replace to make Git use new, LF-only line ending
objects (file data), Git is now happy about the internal storage.
It just takes some shuffling-about to cause these replaced objects
to wind up in Git's *index* AKA *staging area*.
Actually there is something else.
If a file has line-endings that will change, then
git add --renormalize .
git commit -m foo
will commit those files.
But I am now also getting files, that show modified, but that can not be
committed renormalized (0 lines changed).
And that happens with or without refs/replaces.
Any idea how to find out why git thinks they are modified?
git status --porcelain=v2
shows that the file mode is not modified. Only the file in the working tree.
But "git diff" shows nothing (no summary neither). And renormalizing has
no effect.
In fact I started running the following
git rev-list --reverse main | xargs -L 1 sh -c 'git switch --detach
-q -f $0 ; a=$( git status -uno --porcelain=v1 ) ; if [ "$a" != "" ];
then git log --oneline -n1 $0 ; echo $a; fi '
That is, switch to each revision in main (or master). And check if any
file is reported modified.
I just tried that on the gdb git. Plenty of files.
Also other repros have shown modified files.
(I have not yet tried the "git sources" git...
If I then manually switch to some of the commits that had modified files
shown, and I do not switch to all the commits before, then sometimes
there are no modified files.
git fsck has a few dangling commits
git gc made no difference.
