Re: Line ending normalization doesn't work as expected

Torsten Bögershausen <tboegi@web.de> writes:

Both this and its "git read-tree --empty" cousin share a grave issue. The "git add ." step would mean that before doing these commands, your working tree must be truly clean, i.e. the paths in the filesystem known to the index must match what is in the index (modulo the line-ending gotcha you are trying to correct), *AND* there must be *NO* untracked paths you do not want to add in the working tree.

That is a reason why we should solve it differently. Perhaps adding a new option "git add --rehash" to tell Git "Hey, you may think some paths in the index and in the working tree are identical and no need to re-register, but you are WRONG. For each path in the index, remove it and then register the object by hashing the contents from the filesystem afresh!" would be the best way to go. That will not pick up untracked paths left in the filesystem, and does not limit our solution to the "eol normalization is screwey" issue by not calling the option "renormalize" or any other words that imply "why" we are hashing again anew.