All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Nicolas Pitre <nico@cam.org>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: [RFC] Cache negative delta pairs
Date: Thu, 29 Jun 2006 14:26:37 -0700	[thread overview]
Message-ID: <7vbqsbpsaa.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0606291616480.1213@localhost.localdomain> (Nicolas Pitre's message of "Thu, 29 Jun 2006 16:24:01 -0400 (EDT)")

Nicolas Pitre <nico@cam.org> writes:

> The negative delta cache concept is certainly attractive even for normal 
> repositories, especially for public servers, since when used in 
> conjonction with delta reuse it makes the creation of a pack basically 
> free.  So I think this idea really has merits, as long as the cache 
> remains small.

Yes, I agree it is very attractive.

One thing to watch out for is that we probably would not want to
let git-daemon write into public repositories.  Which means that
use of negative cache should be strict "opt-in".

 - "$GIT_DIR/delta-cache" is read but not necessarily is written
   back when it exists; git-daemon uses it that way.

 - The owner of the repository shouldn't have to tell the tool
   to update the negative cache every time repack happens.

Which suggests that pack-objects.c can learn an option that
tells it to call delta_cache_save(), and we use it in
git-repack, perhaps like this:

diff --git a/git-repack.sh b/git-repack.sh
index 640ad8d..b07ed9b 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -44,7 +44,7 @@ case ",$all_into_one," in
 esac
 pack_objects="$pack_objects $local $quiet $no_reuse_delta$extra"
 name=$(git-rev-list --objects --all $rev_list 2>&1 |
-	git-pack-objects --non-empty $pack_objects .tmp-pack) ||
+	git-pack-objects --update-delta-cache --non-empty $pack_objects .tmp-pack) ||
 	exit 1
 if [ -z "$name" ]; then
 	echo Nothing new to pack.
 
diff --git a/pack-objects.c b/pack-objects.c
index bed2497..46b9775 100644
--- a/pack-objects.c
+++ b/pack-objects.c
...
@@ -1342,5 +1350,7 @@ int main(int argc, char **argv)
 	if (progress)
 		fprintf(stderr, "Total %d, written %d (delta %d), reused %d (delta %d)\n",
 			nr_result, written, written_delta, reused, reused_delta);
+	if (update_delta_cache)
+		delta_cache_save();
 	return 0;
 }

  parent reply	other threads:[~2006-06-29 21:26 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060628223744.GA24421@coredump.intra.peff.net>
2006-06-29  3:09 ` [RFC] Cache negative delta pairs Junio C Hamano
2006-06-29  3:50   ` Jeff King
2006-06-29  3:58   ` Jeff King
2006-06-29  4:30     ` Jeff King
2006-06-29 16:39     ` Nicolas Pitre
2006-06-29 18:07       ` Jeff King
2006-06-29 18:48         ` Nicolas Pitre
2006-06-29 18:58           ` Jeff King
2006-06-29 19:06             ` Nicolas Pitre
2006-06-29  4:09   ` Jeff King
2006-06-29 15:42   ` Nicolas Pitre
2006-06-29 16:35     ` Nicolas Pitre
2006-06-29 18:00     ` Jeff King
2006-06-29 18:24       ` Nicolas Pitre
2006-06-29 18:53         ` Jeff King
2006-06-29 19:04           ` Nicolas Pitre
2006-06-29 19:52             ` Jeff King
2006-06-29 20:24               ` Nicolas Pitre
2006-06-29 21:04                 ` Linus Torvalds
2006-06-29 21:24                   ` Nicolas Pitre
2006-06-29 21:30                     ` Linus Torvalds
2006-06-29 21:39                       ` Jeff King
2006-06-29 21:43                       ` Joel Becker
2006-06-29 21:47                       ` Nicolas Pitre
2006-06-29 22:12                         ` Junio C Hamano
2006-06-30  3:44                           ` [PATCH] consider previous pack undeltified object state only when reusing delta data Nicolas Pitre
2006-06-30  9:45                             ` Johannes Schindelin
2006-06-30 12:28                               ` Andreas Ericsson
2006-06-30 16:55                                 ` Nicolas Pitre
2006-07-03  8:11                                   ` Andreas Ericsson
2006-06-29 21:35                   ` [RFC] Cache negative delta pairs Jeff King
2006-06-29 21:54                   ` Junio C Hamano
2006-06-29 22:22                   ` Junio C Hamano
2006-06-29 21:26                 ` Junio C Hamano [this message]
2006-06-29 21:37                 ` Jeff King
2006-06-29 22:31   ` Jakub Narebski

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=7vbqsbpsaa.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=nico@cam.org \
    --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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.