"Philip Oakley via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > From: Philip Oakley <philipoakley@iee.email> > > Bug report > https://lore.kernel.org/git/AM0PR02MB56357CC96B702244F3271014E8DC9@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > noted that a file containing /r/r/n needed renormalising twice. Did you mean backslash, not forward? > This is by design. Lone CR characters, not paired with an LF, are left > unchanged. Note the lack of idempotentness of the "clean" filter in the > documentation. OK. > Renormalize was introduced at 9472935d81e (add: introduce "--renormalize", > Torsten Bögershausen, 2017-11-16) Does this need to be said "HERE", rather than leaving it to run "git blame" for those who became curious? > Signed-off-by: Philip Oakley <philipoakley@iee.email> > --- > Documentation/git-add.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt > index 11eb70f16c7..c4a5ad11a6b 100644 > --- a/Documentation/git-add.txt > +++ b/Documentation/git-add.txt > @@ -188,7 +188,8 @@ for "git add --no-all <pathspec>...", i.e. ignored removed files. > forcibly add them again to the index. This is useful after > changing `core.autocrlf` configuration or the `text` attribute > in order to correct files added with wrong CRLF/LF line endings. > - This option implies `-u`. > + This option implies `-u`. Lone CR characters are untouched, so > + cleaning not idempotent. A CRCRLF sequence cleans to CRLF. Lack of verb BE somewhere. Do we expect our readers all understand the math-y word? It is not too hard to explain it to math-uninitiated, e.g. This option implies `-u`. Note that running renormalize again on the result of running renormalize may make it even "more normal". A CR-CR-LF sequence would first renormalize to CR-LF (the first CR, a lone CR, is left intact, and CR-LF that follows normalizes to LF). If you run renormalize again, the resulting CR-LF will normalize down to LF.
