On Thu, Nov 16, 2017 at 11:38 AM, <tboegi@xxxxxx> wrote:
> Make it safer to normalize the line endings in a repository:
> Files that had been commited with CRLF will be commited with LF.
>
> The old way to normalize a repo was like this:
> # Make sure that there are not untracked files
> $ echo "* text=auto" >.gitattributes
> $ git read-tree --empty
> $ git add .
> $ git commit -m "Introduce end-of-line normalization"
>
> The user must make sure that there are no untracked files,
> otherwise they would have been added and tracked from now on.
>
> The new "add ..renormalize" does not add untracked files:
> $ echo "* text=auto" >.gitattributes
> $ git add --renormalize .
> $ git commit -m "Introduce end-of-line normalization"
>
> Note that "git add --renormalize <pathspec>" is the short form for
> "git add -u --renormalize <pathspec>".
>
> While add it, document that the same renormalization may be needed,
> whenever a clean filter is added or changed.
Forgive me for chiming in so late, but as a newcomer to this topic,
the high-level choice made by this patch feels a bit questionable. I
understand that, for people familiar with the "old way" of normalizing
files, git-add might seems like the right place to house this
functionality (and perhaps that's true from an implementation angle?),
but as one coming to this topic with no existing bias about
implementation or the "old way", git-add feels like an odd choice.
This sort of normalization (emptying the index, potentially modifying
files, repopulating the index) seems too high-level for git-add.
I _could_ understand if this functionality lived in, say, a new
command git-attr:
SYNOPSIS
git attr renormalize [--no-commit | [-m <msg>]] pathname...
git attr check [-a | --all | attr…] [--] pathname…
git attr check --stdin [-z] [-a | --all | attr…]
DESCRIPTION
'git attr renormalize'
Apply the "clean" process ... and commit the results. This is
useful after changing `core.autocrlf` ... etc. With '-m', uses
<msg> as the commit message, else launches the editor. Use
'--no-commit' to skip the automatic commit.
The 'git attr check' command subsumes the role of existing
git-check-attr. One could envision git-attr growing additional
subcommands to edit .gitattributes, much like git-config edits
.gitconfig.
(I have since read the thread in which Junio's suggested[1] that
git-add could house this functionality, but it still feels too
high-level.)
More below...
> Signed-off-by: Torsten Bögershausen <tboegi@xxxxxx>
> ---
> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
> @@ -175,6 +175,13 @@ for "git add --no-all <pathspec>...", i.e. ignored removed files.
> +--renormalize::
> + Apply the "clean" process freshly to all tracked files to
This is the only time "clean" appears in git-add documentation. Every
newcomer to git learns about git-add very early on, but "clean
process" is a fairly advanced topic, unlikely to be on a newcomer's
radar. The term "renormalize" also feels out of place in git-add
documentation. If I was a newcomer reading git-add documentation, I
think I'd be left pretty well clueless by this description. At the
very least, perhaps add links to git-attributes and 'core.autocflf'
configuration.
> + 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`.
[1]: https://public-inbox.org/git/xmqqbmlm9y94.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx/
