On Thu, Feb 23, 2012 at 07:42:11PM -0800, Junio C Hamano wrote:
> It is a bit curious that anything filtered even goes to the streaming
> codepath, given this piece of code in write_entry() in entry.c:
>
> if (ce_mode_s_ifmt == S_IFREG) {
> struct stream_filter *filter = get_stream_filter(path, ce->sha1);
> if (filter &&
> !streaming_write_entry(ce, path, filter,
> state, to_tempfile,
> &fstat_done, &st))
> goto finish;
> }
>
> and get_stream_filter() in convert.c has an explicit exception for this
> case at the very beginning:
I think it is because we don't follow that code path at all. The stack trace
for "git add" looks on a large file looks like:
#0 stream_to_pack (...) at bulk-checkin.c:101
#1 deflate_to_pack (...) at bulk-checkin.c:219
#2 index_bulk_checkin (...) at bulk-checkin.c:258
#3 index_stream (...) at sha1_file.c:2712
#4 index_fd (...) at sha1_file.c:2726
#5 index_path (...) at sha1_file.c:2742
#6 add_to_index (...) at read-cache.c:644
#7 add_file_to_index (...) at read-cache.c:673
#8 add_files (...) at builtin/add.c:363
#9 cmd_add (...) at builtin/add.c:474
#10 run_builtin (...) at git.c:324
#11 handle_internal_command (...) at git.c:484
#12 run_argv (...) at git.c:530
#13 main (...) at git.c:605
Isn't write_entry the _other_ side of things. I.e., checking out, not
checking in? That side works fine (making the large file handling
for git-add even more odd. We will fail to apply the "clean" filter when
adding it, but we will apply the smudge filter when we write it out).
-Peff
--
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