Git development
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Jon Jensen <jon@endpoint.com>,
	git@vger.kernel.org
Subject: Re: How to stop sharing objects between repositories
Date: Mon, 17 Aug 2009 02:19:17 -0400	[thread overview]
Message-ID: <20090817061916.GA27530@coredump.intra.peff.net> (raw)
In-Reply-To: <7vmy5z603d.fsf@alter.siamese.dyndns.org>

On Sun, Aug 16, 2009 at 12:16:22PM -0700, Junio C Hamano wrote:

> After reading this, two points come to my mind.  They may or may not be
> issues.
> 
>  (1) Such a user does not necessarily know a casual "git repack -a" breaks
>      the dependency, defeating the -s option s/he deliberately used in
>      order to save disk space in the first place.  Perhaps we can reword
>      this further to kill two penguins with a single stone?
> 
> 	Note that the pack resulting from running `git repack -a` in the
> 	repository cloned with the `-s` option will include objects that
> 	are borrowed from the source repository.  It essentially breaks
> 	the dependency created by cloning with the `-s` option by copying
> 	the objects from the source repository.  To keep borrowing from
> 	the source repository to save disk space, do not use `repack -a`.

Good point, but I don't think this wording is quite right. You can also
cause such an inefficiency by simply running "git repack", if the source
has loose objects. In other words:

  1. "git repack -a" is sufficient to break dependency, as it copies
     both packed and loose objects

  2. "git repack" _may_ break the dependency, if there are no packs, as
     it copies only loose objects. It _may_ introduce inefficiency, but
     only if there are loose objects.

  3. "git repack -l" always keeps the dependency and current efficiency.

     As an aside, making this list makes me realize there is no easy
     "keep the dependency and increase efficiency". In other words, pack
     everything that is not available otherwise, and then prune the
     remaining packs.

Modified patch is below.

>      We should suggest an alternative immediately after this sentence,
>      e.g. "Instead, use `repack -l`" or something, but somebody should
>      check if it is a valid/viable alternative.

It does work. From a user's perspective, I think "-l" would probably be
a more sane default. But I think it is off for historical reasons, and
these days we try to steer users towards "git gc", anyway, which does
use "-l" by default.

-- >8 --
Subject: [PATCH] docs: describe impact of repack on "clone -s"

The effects of repacking on a repository with alternates are
a bit subtle. The two main things users will want are:

  1. Not to waste disk space by accidentally copying objects
     which could be shared.

  2. Copying all objects explicitly to break the dependency
     on the source repo.

This patch describes both under the "clone -s"
documentation. It makes sense to put it there rather than in
git-repack.txt for both cases. For (1), we are warning the
user who is using "clone -s" about what _not_ to do, so we
need to get their attention when reading about "clone -s".
For (2), we are telling them how git-repack can be used to
accomplish a task, but until they know that git-repack is
the right tool, they have no reason to look at the repack
documentation.

Signed-off-by: Jeff King <peff@peff.net>
---

The extra deleted lines in the patch below are just cleaning up some
excess whitespace.

 Documentation/git-clone.txt |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index b14de6c..b25944f 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -72,8 +72,16 @@ These objects may be removed by normal git operations (such as 'git-commit')
 which automatically call `git gc --auto`. (See linkgit:git-gc[1].)
 If these objects are removed and were referenced by the cloned repository,
 then the cloned repository will become corrupt.
-
-
++
+Note that running `git repack` without the `-l` option in a repository
+cloned with `-s` will copy objects from the source repository into a
+pack in the cloned repository, removing the disk space savings of `clone
+-s`. It is safe, however, to run `git gc`, which uses the `-l` option by
+default.
++
+If you want to break the dependency of a repository cloned with `-s` on
+its source repository, you can simply run `git repack -a` to copy all
+objects from the source repository into a pack in the cloned repository.
 
 --reference <repository>::
 	If the reference repository is on the local machine
-- 
1.6.4.283.gec993

  parent reply	other threads:[~2009-08-17  6:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-16  0:04 How to stop sharing objects between repositories Jon Jensen
2009-08-16  8:43 ` Johannes Schindelin
2009-08-16 12:28   ` Jeff King
2009-08-16 12:30     ` Johannes Schindelin
2009-08-16 13:54       ` Daniel Villeneuve
2009-08-16 13:57         ` Johannes Schindelin
2009-08-16 13:57       ` Jeff King
2009-08-16 19:16         ` Junio C Hamano
2009-08-17  2:21           ` Mike Galbraith
2009-08-17  6:48             ` Jeff King
2009-08-17  7:12               ` Mike Galbraith
2009-08-17  7:24               ` Junio C Hamano
2009-08-17  7:25                 ` Jeff King
2009-08-17  7:35                   ` Junio C Hamano
2009-08-17  7:50                     ` Jeff King
2009-08-17  6:19           ` Jeff King [this message]
2009-08-17  6:32             ` Jeff King
2009-08-17  6:31           ` Jeff King

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

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

  git send-email \
    --in-reply-to=20090817061916.GA27530@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jon@endpoint.com \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox