Re: [PATCH v4 4/8] diff: Filter files that have changed only due to conversion changes.

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 10, 2010, 22:37 UTC
Message-ID: <7vvdbzszmi.fsf@alter.siamese.dyndns.org>
In-Reply-To: <3daab2593b3f83971c6da6cfcd3d56046c84477a.1270554878.git.grubba@grubba.org>

"Henrik Grubbström (Grubba)"  <grubba@grubba.org> writes:

Show 6 quoted lines

> When the conversion filter for a file is changed, files may get listed
> as modified even though the user has not made any changes to them.
> This patch adds a configuration option 'core.refilterOnDiff', which
> performs an extra renormalization pass to filter out such files.
>
> Signed-off-by: Henrik Grubbström <grubba@grubba.org>

Does this really have to be done for every invocation of diff?

It is a problem worthy of a clean solution that changing the filtering options makes files that are not really different (from the end user's point of view).

But the problem feels very similar to the issue that touching the inode information would make the cached stat information in the index invalid and plumbing commands such as "diff-files" would report phantom changes.

And the way we solve the latter issue without undue overhead for all command invocations is with "update-index --refresh" (either run directly as a command inside Porcelain scripts that work with the plumbing, or internally by calling refresh_cache() API in the C implementations of Porcelain commands). Hence:

	$ cat Makefile >Makefile+
        $ mv Makefile+ Makefile
        $ git diff-files --name-only
        Makefile
        $ git update-index --refresh
        $ git diff-files --name-only

once we spend cycles to revalidate the cached information in the index, subsequent commands can trust the validity information without recomputing the phantom differences that do not exist over and over.

I wonder if we can solve this in a similar way. Especially, because changing filtering options like the core.crlf settings is a one-off event that is done even rarely than "touch Makefile", it doesn't feel right to add an extra configuration that makes people pay the penalty during everyday use just in case such a one-off event might have happened.

> The typical reason to enable this option is when you have lots of files
> that have been affected by a configuration change (eg crlf convention
> or ident expansion), but don't want to recommit the otherwise unchanged
> files just to get them on canonic form in the repository.

Of course you do not want to re-commit. If however these files that are unchanged from the end-user's point of view can be re-checked out safely, then that would be similar to what "update-index --refresh" does for paths that are stat-dirty.