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

Dmitry Potapov <dpotapov@gmail.com> writes:

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.