"Henrik Grubbström (Grubba)" <grubba@xxxxxxxxxx> writes:
> 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@xxxxxxxxxx>
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html