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

[Chris Torek <chris.torek@gmail.com>]

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