Do you use "git-apply --show-files"?

As a part of "funny pathname character" updates, I was reviewing
"apply.c" and have two questions on its "--show-files" flag.

 * Unlike other informational flags like --stat and --summary,
   it does not turn off "apply".  Is it intentional? 

 * Do you (or anybody else) use it, and if so how?

The current code in the proposed updates branch decodes the same
C-style encoded pathnames GNU patch with proposed enhancements
would understand before applying patches, and when it needs to
show pathnames with --index-info, --stat, and --summary, it uses
the same encoded pathname to keep things on one line.

I think --show-files should also do the same for consistency,
but before I update it I wanted to ask the above questions.  If
nobody uses it, I can just ignore the issues and probably
remove the flag.

The plan is to backport the git-apply change to the maint branch
to do a 0.99.8e before updated git-diff-* hits the master
branch.  The only thing that would make a difference is embedded
SP.  Currently they are not quoted, but they will be, like this:

        : siamese; git diff
        diff --git "a/Read Me" "b/Read Me"
        index 3deac99..543a8f0 100644
        --- "a/Read Me"
        +++ "b/Read Me"
        ...

On Sun, 16 Oct 2005, Junio C Hamano wrote:

As a part of "funny pathname character" updates, I was reviewing
"apply.c" and have two questions on its "--show-files" flag.

 * Unlike other informational flags like --stat and --summary,
   it does not turn off "apply".  Is it intentional? 

 * Do you (or anybody else) use it, and if so how?

As far as I'm concerned, you can remove it.

The point of show-files was to have the index update be based on the files 
that were updated, it I was originally not planning to updating the index 
directly in git-apply, but instead do something like

	files=$(git-apply --show-files)
	git-update-cache --add --delete -- $files

but it turned out to be a lot easier to just update the index.

So just remove that flag, I doubt it has ever been used.

		Linus