Torsten Bögershausen <tbo...@web.de> writes:
>> > +--renormalize::
>> > + Normalizes the line endings from CRLF to LF of tracked files.
>> > + This applies to files which are either "text" or "text=auto"
>> > + in .gitattributes (or core.autocrlf is true or input)
>> > + --renormalize implies -u
>> > +
>>
>> OK.
>
> I think the fact, that clean filters are re-run, and re-evaluated
> in case they are changed, should be made more clear here.
> I don't know how to explain it better that CRLF conversion and/or filters are
> re-applied, this is an attempt:
>
>
> --renormalize::
> Normalizes the line endings from CRLF to LF of tracked files,
> if the .gitattributes or core.autocrlf say so.
> Additionally the clean and ident filters, if any, are re-run.
> --renormalize implies -u
That is certainly better. Do we have an end-user facing phrase to
collectively call everything the "convert_to_git()" processing does?
When I talk casually about it, I'd call it the "clean" process (as
opposed to the "smudge" process) as a term that includes all the
things that Git does to massage contents in the working tree to
in-repository representation.
If we had such a term in Documentation/glossary-contents.txt, we
could even say
Add contents of all paths to the index by freshly applying
the "clean" process, even to the ones Git may think are
unmodified in the working tree since they were added the
last time (based on the file timestamps etc.). This is
often useful after updating settings like `core.autocrlf` in
the `.git/config` file and the `text` attributes in the
`.gitattributes` file to correct the index entries that
records lines with CRLF to use LF instead, or changing what
the `clean` filter does. This option implies `-u`.
The point is to express that the CRLF/LF is a consequence (even
though it may be the most prominent one from end-users' point of
view) of a larger processing.
> [snip the TC. Adding line endings is good)
What is TC in this context?
