Re: [PATCH v3 1/1] Introduce git add --renormalize .

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Nov 17, 2017, 20:44 UTC
Message-ID: <CAPig+cQocmJyoALeQeCRQPNsRgvJ5PSe=u2LN8Ec6aC86D4iQw@mail.gmail.com>
In-Reply-To: <20171116163828.14937-1-tboegi@web.de>

On Thu, Nov 16, 2017 at 11:38 AM,  <tboegi@web.de> wrote:

Show 23 quoted lines

> 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...

Show 6 quoted lines

> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
> ---
> 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@gitster.mtv.corp.google.com/