git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Jacob Keller <jacob.keller@gmail.com>,
	Jonathan Tan <jonathantanmy@google.com>,
	Git mailing list <git@vger.kernel.org>
Subject: Re: [PATCH] Doc: clarify that pack-objects makes packs, plural
Date: Thu, 24 Aug 2017 12:09:02 -0700	[thread overview]
Message-ID: <xmqqd17kwzox.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170824133842.vqzydienll6ka4vw@sigill.intra.peff.net> (Jeff King's message of "Thu, 24 Aug 2017 06:38:43 -0700")

Jeff King <peff@peff.net> writes:

> On Thu, Aug 24, 2017 at 12:27:52AM -0700, Jacob Keller wrote:
>
>> > For the sneaker-net case, you are much better off generating a single
>> > pack and then using "split" and "cat" to reconstruct it on the other end
>> > Not that I think we should go into such detail in the manpage, but I
>> > have to wonder if --max-pack-size has outlived its usefulness. The only
>> > use case I can think of is a filesystem that cannot hold files larger
>> > than N bytes.
>> 
>> Is it possible to detect on the file system that we can't store files
>> that large, and remove the option, while enabling it only when we
>> detect the filesystem is unable to store large files?
>
> I'm not sure how easy it would be to do such a check. But even if it
> was, I'm not sure that buys us much. We'd still carry the code. We could
> in theory remove the option, simplifying the interface. But that removes
> the possibility of somebody wanting to stage the smaller packfiles on a
> more capable filesystem in preparation for moving them to the
> more-limited one.

I agree that it would not help anybody to _disable_ --max-pack-size
feature for those on certain filesystems, but it _might_ make sense
to automatically _enable_ it (and set it to the maximum number) when
your destination filesystem is limited.

Even in that case, failing with an error code from the filesystem
and then asking the user to redo with --max-pack-size specified
wouldn't be the end of the world, though.

      reply	other threads:[~2017-08-24 19:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-22 18:22 [PATCH] Doc: clarify that pack-objects makes packs, plural Jonathan Tan
2017-08-22 19:56 ` Junio C Hamano
2017-08-23  0:40   ` [PATCH v2] " Jonathan Tan
2017-08-23 21:22   ` [PATCH] " Jeff King
2017-08-24  7:27     ` Jacob Keller
2017-08-24 13:38       ` Jeff King
2017-08-24 19:09         ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqd17kwzox.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jacob.keller@gmail.com \
    --cc=jonathantanmy@google.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).