git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stephen Boyd <bebarino@gmail.com>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: git@vger.kernel.org, lists@informa.tiker.net,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCHv1+eps] git-repack.txt: Clarify implications of -a for dumb  protocols
Date: Fri, 5 Jun 2009 12:14:15 -0700	[thread overview]
Message-ID: <780e0a6b0906051214t76f2bf37u96cc0b8039f63d23@mail.gmail.com> (raw)
In-Reply-To: <4A28D470.5030403@drmicha.warpmail.net>

On Fri, Jun 5, 2009 at 1:16 AM, Michael J
Gruber<git@drmicha.warpmail.net> wrote:
> Stephen Boyd venit, vidit, dixit 04.06.2009 21:46:
>> Instead of adding this, why don't we just remove the part about dumb
>> protocols? So just say that it's especially useful for private
>> development. Then, if we really want to keep this performance note
>> just add it after the paragraph in one of those "+" things (What are
>> those called?)
>
> ...because "repack -a" hurts *badly* on even midsized repos when dumb
> protocols are used. On the other hand, using it isn't that much of an
> improvement in terms of pack size, unless you repack manually very often
> and, thus, produce many small packs. So, "gc --auto" users should be
> fine in any case (dumb or not - the protocol, that is...) as long as
> they don't use "-a".

Maybe I spoke wrongly. I'm suggesting something like

       Especially useful when packing a repository that is used
       for private development.  Use with '-d'.  This will clean up
       the objects that `git prune` leaves behind, but
       `git fsck --full` shows as dangling.
+
Note: Users fetching over dumb protocols will have to fetch the
whole pack in order to get any contained object, no matter how
many other objects in that pack they already have locally.

I think this Note part probably needs some work though.

  reply	other threads:[~2009-06-05 19:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-03 23:50 git repack and dumb protocols Andreas Klöckner
2009-06-04 10:58 ` [PATCH] git-pack.txt: Clarify implications of -a for " Michael J Gruber
2009-06-04 11:34 ` [PATCHv1+eps] git-repack.txt: " Michael J Gruber
2009-06-04 13:34   ` Andreas Klöckner
2009-06-04 19:46   ` Stephen Boyd
2009-06-05  8:16     ` Michael J Gruber
2009-06-05 19:14       ` Stephen Boyd [this message]
2009-06-09 16:15         ` [PATCH] " Michael J Gruber
2009-06-04 12:47 ` git repack and " Peter Harris

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=780e0a6b0906051214t76f2bf37u96cc0b8039f63d23@mail.gmail.com \
    --to=bebarino@gmail.com \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=lists@informa.tiker.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).