"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes:
> ... The output file is opened by pack-objects after
> object enumeration and delete compression are done, ...
s/delete/deflate/, I guess.
> diff --git a/sha1_file.c b/sha1_file.c
> index d949b35..8863ff6 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -708,9 +713,35 @@ static int open_packed_git_1(struct packed_git *p)
> if (!p->index_data && open_pack_index(p))
> return error("packfile %s index unavailable", p->pack_name);
>
> + if (!pack_max_fds) {
> + ...
> + if (lim.rlim_cur < lim.rlim_max) {
> + lim.rlim_cur = lim.rlim_max;
> + if (!setrlimit(RLIMIT_NOFILE, &lim))
> + max_fds = lim.rlim_max;
> + }
This is somewhat questionable, isn't it? We don't know why the user chose
to ulimit the process yet forcibly bust that limit without telling him?
Other than that it looks sensible. Thanks.
--
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