Dmitry Potapov <dpotapov@xxxxxxxxx> 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.
--
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
