Re: [PATCH] hash-object --no-filters

[Junio C Hamano <gitster@pobox.com>]

Dmitry Potapov <dpotapov@gmail.com> writes:

> The --no-filters option makes git hash-object to work as there were no
> input filters. This option is useful for importers such as git-svn to
> put new version of files as is even if autocrlf is set.

I think this is going in the right direction, but I have to wonder a few
things.

First, on hash-object.

 (1) "hash-object --stdin" always hashes literally.  We may want to be
     able to say "The contents is this but pretend it came from this path
     and apply the usual input rules", perhaps with "--path=" option;

 (2) "hash-object temporaryfile" may want to honor the same "--path"
     option;

 (3) "hash-object --stdin-paths" may want to get pair of paths (i.e. two
     lines per entry) to do the same.

If we want to do the above, the existing low-level interface needs to be
adjusted.

index_pipe() and index_fd() can learn to take an additional string
parameter for attribute lookup to implement (1) and (2) above.  Perhaps
the string can be NULL to signal --no-filter behaviour, in which case the
HASH_OBJECT_LITERALLY change may not be necessary for this codepath.

index_path() is a healper for add_to_index() which is used for normal
addition of working tree entities, and I do not see an immediate need to
teach it about this "use this different path for attribute lookup" at
least for now.

By the way, why do we have index_pipe() and index_fd() to begin with?  Is
it because users of index_pipe() do not know what the path it is hashing
and also the fd being a pipe we cannot mmap it?

If these two are the only reasons, then I wonder if we can:

 - accept NULL as path and stat parameters for callers without a filename
   (which automatically implies we are doing a regular blob and we hash
   literally); and

 - first try to mmap(), and if it fails fall back to the "read once into
   strbuf" codepath to solve mmap-vs-pipe issue.

I am not sure if such a unification of these two functions is useful,
though.