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

From: Chris Torek <chris.torek@gmail.com>
Date: Jul 26, 2021, 11:11 UTC
Message-ID: <CAPx1GvfH0Rqz238GUByBGkrRK8UeBpF3-1XvW_M66_w6DVgYFA@mail.gmail.com>
In-Reply-To: <f454bf5b-c5ff-4140-02a8-b02dcd35c6b9@mfriebe.de>

I don't have Windows and hence cannot test your exact situation (which I understand to be:

    `core.autocrlf` set to `true`

and of course "using Windows"). I will repeat that I think setting `core.autocrlf` to `true` is a bad idea, though.

In the meantime:

On Mon, Jul 26, 2021 at 3:31 AM Martin <git@mfriebe.de> wrote:

> origin  git://sourceware.org/git/binutils-gdb.git (fetch)

I cloned this repository so as to be able to obtain its commits.

> fsck had some dangling commits, I did a "git gc --aggressive".

(Dangling commits are irrelevant and unimportant: there's no need to do this.)

> Switching to a far away commit
> git switch -f --detach master
> git rev-list master | wc -l
> 93917

The actual hash ID of the commit would be potentially useful here (whether it's really useful would depend on whether I have or can obtain that commit).

I do see that commit 16788ca9fd7352b2b20f4b11111283a8cd4212e2 removed various `Makefile.dos` files, including one mentioned below (`bfd/Makefile.dos`). That's the only file name I looked at specifically for this kind of operation initially (I checked another just now and it too went away in that commit).

> ... Then switching to  (this is on master branch)
> git switch -f --detach a362ee23634

The hash ID is all that matters: branch names are irrelevant here.

This commit contains a `bfd/Makefile.dos`. The actual line endings in this file are LF-only.

> git status --porcelain=v2
> 1 .M N... 100644 100644 100644 9e677a52ae690808165993a0f3f17ac49e3969df
> 9e677a52ae690808165993a0f3f17ac49e3969df bfd/Makefile.dos

This is also useful:

 * The `.M` means that the committed copy of the file matches
   the index copy, while the index copy does not match the working
   tree copy (presumably because the working tree copy has had
   its line endings changed to CRLF).
 * The `N...` means that this is not a submodule.
 * The three `100644`s mean that the file is mode 100644 in
   the commit, the index, and the working tree.
 * The two hash IDs are the blob object hash IDs for the committed
   and index copies of the file data; these match.
 * Last, we have the file's name in the index.

The same pattern seems to repeat for the remaining files.

These "Makefile.dos" files seem to be hardly ever touched, in any commit, so these four files are likely not to be swapped out by `git checkout` or `git switch` operations.

> My question is are there any plumbing commands, that could allow me to
> look further at it.

The simplest is to get the raw hash ID of any existing Git-ized object, and use `git cat-file -p <hash>` on that object. Since `git cat-file` has no idea whether the data are to be treated as text or binary (in this case where there is no path name and no `--textconv` flag),it just writes out the raw text. You must, however, make sure that the output from this command is not mangled by some other tool (e.g., some Windows editor "helpfully" changing LF-only to CRLF).

Note that `git ls-tree`, with the `-r` (recursive) option, allows you to inspect the raw hash IDs of committed files by their path names.

Chris