threads / discuss / 24218

notify alternative to auto gc?

Subject: notify alternative to auto gc?

## tl;dr

21 messages between Jun 28, 2010 and Sep 21, 2010.

replies: 20people: 10as markdown or json

Karl Stenerud· Jun 28, 2010, 16:10 UTC · lore
Hi,
As I did a git pull on my project today, git went into some kind of auto gc mode:

Auto packing the repository for optimum performance. You may also run "git gc" manually. See "git help gc" for more information. Counting objects: 4531, done.

This is, of course, quite an annoying feature since it could hit at any (inconvenient) time.
The git help tells me I can disable it by setting gc.auto to 0, while the mailing list archive tells me I also have to set gc.autopacklimit to 0.  This is fine, but if I do that, I won't know when the repo is in need of cleanup.  Is there any option I can set to instruct it to simply TELL me when it's in need of gc?
Ævar Arnfjörð Bjarmason· Jun 28, 2010, 16:26 UTC · re: Karl Stenerud · lore

Re: notify alternative to auto gc?

On Mon, Jun 28, 2010 at 16:10, Karl Stenerud <kstenerud@gmail.com> wrote:
> The git help tells me I can disable it by setting gc.auto to 0, while the mailing list archive tells me I also have to set gc.autopacklimit to 0.  This is fine, but if I do that, I won't know when the repo is in need of cleanup.  Is there any option I can set to instruct it to simply TELL me when it's in need of gc?

Anything that tells you whether you need to gc would incur much of the speed penalty that running gc itself does.

Karl Stenerud· Jun 28, 2010, 16:52 UTC · re: Ævar Arnfjörð Bjarmason · lore

Re: notify alternative to auto gc?

On 2010-06-28, at 12:26 PM, Ævar Arnfjörð Bjarmason wrote:
Show 5 quoted lines
> On Mon, Jun 28, 2010 at 16:10, Karl Stenerud <kstenerud@gmail.com> wrote:
>> The git help tells me I can disable it by setting gc.auto to 0, while the mailing list archive tells me I also have to set gc.autopacklimit to 0.  This is fine, but if I do that, I won't know when the repo is in need of cleanup.  Is there any option I can set to instruct it to simply TELL me when it's in need of gc?
> 
> Anything that tells you whether you need to gc would incur much of the
> speed penalty that running gc itself does.
Actually, no it wouldn't.  If checking did incur much of the speed penalty, then git, in general, would already be horribly slow all the time because it automatically does a gc-check with most commonly used commands, according to the documentation.
In the case which I observed, the time from typing "git pull" until the auto-gc notification was a few seconds.  The time from the notification until gc completion, however, was 3-4 minutes.
Matthieu Moy· Jun 29, 2010, 06:46 UTC · re: Karl Stenerud · lore

Re: notify alternative to auto gc?

Karl Stenerud <kstenerud@gmail.com> writes:
> In the case which I observed, the time from typing "git pull" until
> the auto-gc notification was a few seconds.  The time from the
> notification until gc completion, however, was 3-4 minutes.
The missing bit here is how often this happens.

Once you did an actual "git gc", your repository is stored in a single pack file, and only new files are stored unpacked or in separate packs. Subsequent "git gc --auto" will just pack unpacked objects together by groups of approximately "gc.auto" (i.e. 6700), which is quick, until you reach "gc.packlimit" (i.e. 50). You'll trigger an expansive repack only after that. So, roughly, you'll get an expansive repack after creating 300,000 object files (unless you ran "git gc" in the meantime). Unless you do very nasty things with your repo, that really means "not often", and especially "not often enough that you should care" in 99.9% cases.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Sam Vilain· Jun 30, 2010, 02:27 UTC · re: Ævar Arnfjörð Bjarmason · lore

Re: notify alternative to auto gc?

On Mon, 2010-06-28 at 16:26 +0000, Ævar Arnfjörð Bjarmason wrote:
Show 5 quoted lines
> On Mon, Jun 28, 2010 at 16:10, Karl Stenerud <kstenerud@gmail.com> wrote:
> > The git help tells me I can disable it by setting gc.auto to 0, while the mailing list archive tells me I also have to set gc.autopacklimit to 0.  This is fine, but if I do that, I won't know when the repo is in need of cleanup.  Is there any option I can set to instruct it to simply TELL me when it's in need of gc?
> 
> Anything that tells you whether you need to gc would incur much of the
> speed penalty that running gc itself does.
See builtin/gc.c:too_many_loose_objects

Checking that gc is required involves opening one directory (objects/17 IIRC), reading all of the entries in it and counting them. It really doesn't hurt.

Sam
Matthieu Moy· Jun 28, 2010, 16:27 UTC · re: Karl Stenerud · lore

Re: notify alternative to auto gc?

Karl Stenerud <kstenerud@gmail.com> writes:
Show 5 quoted lines
> The git help tells me I can disable it by setting gc.auto to 0,
> while the mailing list archive tells me I also have to set
> gc.autopacklimit to 0.  This is fine, but if I do that, I won't know
> when the repo is in need of cleanup.  Is there any option I can set
> to instruct it to simply TELL me when it's in need of gc?

An alternative is to actually run "git gc" periodically, to make sure that git gc --auto is never needed.

I do that from a cron job for example.
-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Chris Packham· Jun 28, 2010, 16:29 UTC · re: Karl Stenerud · lore

Re: notify alternative to auto gc?

On Mon, Jun 28, 2010 at 9:10 AM, Karl Stenerud <kstenerud@gmail.com> wrote:
Show 12 quoted lines
> Hi,
>
> As I did a git pull on my project today, git went into some kind of auto gc mode:
>
> Auto packing the repository for optimum performance. You may also
> run "git gc" manually. See "git help gc" for more information.
> Counting objects: 4531, done.
>
> This is, of course, quite an annoying feature since it could hit at any (inconvenient) time.
>
> The git help tells me I can disable it by setting gc.auto to 0, while the mailing list archive tells me I also have to set gc.autopacklimit to 0.  This is fine, but if I do that, I won't know when the repo is in need of cleanup.  Is there any option I can set to instruct it to simply TELL me when it's in need of gc?
>

I don't think there is an existing configuration for this but I think you can achieve what you want with the "pre-auto-gc" hook. From the githooks(5) man page

  pre-auto-gc
     This hook is invoked by git gc --auto. It takes no parameter, and
     exiting with non-zero status from this script causes the git gc --auto
     to abort.
So a hook like
  #! /bin/sh
  echo "repository needs git gc"
  exit 1
Should cause the auto gc to be skipped.
Karl Stenerud· Jun 28, 2010, 16:56 UTC · re: Chris Packham · lore

Re: notify alternative to auto gc?

On 2010-06-28, at 12:29 PM, Chris Packham wrote:
Show 30 quoted lines
> On Mon, Jun 28, 2010 at 9:10 AM, Karl Stenerud <kstenerud@gmail.com> wrote:
>> Hi,
>> 
>> As I did a git pull on my project today, git went into some kind of auto gc mode:
>> 
>> Auto packing the repository for optimum performance. You may also
>> run "git gc" manually. See "git help gc" for more information.
>> Counting objects: 4531, done.
>> 
>> This is, of course, quite an annoying feature since it could hit at any (inconvenient) time.
>> 
>> The git help tells me I can disable it by setting gc.auto to 0, while the mailing list archive tells me I also have to set gc.autopacklimit to 0.  This is fine, but if I do that, I won't know when the repo is in need of cleanup.  Is there any option I can set to instruct it to simply TELL me when it's in need of gc?
>> 
> 
> I don't think there is an existing configuration for this but I think
> you can achieve what you want with the "pre-auto-gc" hook. From the
> githooks(5) man page
> 
>  pre-auto-gc
>     This hook is invoked by git gc --auto. It takes no parameter, and
>     exiting with non-zero status from this script causes the git gc --auto
>     to abort.
> 
> So a hook like
> 
>  #! /bin/sh
>  echo "repository needs git gc"
>  exit 1
> 
> Should cause the auto gc to be skipped.
Cool thanks!  I'll give that a shot.
Chris Packham· Jun 28, 2010, 17:07 UTC · re: Chris Packham · lore

[PATCH/RFC] Documentation/git-gc.txt: add reference to githooks

This advertises the existence of the 'pre-auto-gc' hook and adds a cross reference to where the hook is documented.

Signed-off-by: Chris Packham <judge.packham@gmail.com>
---
I had to go fishing in the code to find out about the pre-auto-gc hook. From
reading the git-gc man page it wasn't obvious to me that there would be a hook
for 'git gc --auto'. The relevant config variables are mentioned so it seems
logical to mention the hooks also. The only precedent I found for this was in
the git-commit man page which has a section listing the hooks that are
available.
 Documentation/git-gc.txt |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index a9e0882..a514c52 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -137,6 +137,11 @@ If you are expecting some objects to be collected and they aren't, check
 all of those locations and decide whether it makes sense in your case to
 remove those references.
 
+HOOKS
+-----
+This command can run `pre-auto-gc` hook.  See linkgit:githooks[5] for more
+information.
+
 SEE ALSO
 --------
 linkgit:git-prune[1]
-- 
1.7.1
Marc Branchaud· Jun 28, 2010, 18:43 UTC · re: Chris Packham · lore

Re: [PATCH/RFC] Documentation/git-gc.txt: add reference to githooks

How about also adding a templates/hooks--pre-auto-gc.sample file?
		M.
On 10-06-28 01:07 PM, Chris Packham wrote:
Show 31 quoted lines
> This advertises the existence of the 'pre-auto-gc' hook and adds a cross
> reference to where the hook is documented.
> 
> Signed-off-by: Chris Packham <judge.packham@gmail.com>
> ---
> I had to go fishing in the code to find out about the pre-auto-gc hook. From
> reading the git-gc man page it wasn't obvious to me that there would be a hook
> for 'git gc --auto'. The relevant config variables are mentioned so it seems
> logical to mention the hooks also. The only precedent I found for this was in
> the git-commit man page which has a section listing the hooks that are
> available.
> 
>  Documentation/git-gc.txt |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
> index a9e0882..a514c52 100644
> --- a/Documentation/git-gc.txt
> +++ b/Documentation/git-gc.txt
> @@ -137,6 +137,11 @@ If you are expecting some objects to be collected and they aren't, check
>  all of those locations and decide whether it makes sense in your case to
>  remove those references.
>  
> +HOOKS
> +-----
> +This command can run `pre-auto-gc` hook.  See linkgit:githooks[5] for more
> +information.
> +
>  SEE ALSO
>  --------
>  linkgit:git-prune[1]
Junio C Hamano· Jun 29, 2010, 15:43 UTC · re: Marc Branchaud · lore

Re: [PATCH/RFC] Documentation/git-gc.txt: add reference to githooks

Marc Branchaud <marcnarc@xiplink.com> writes:
> How about also adding a templates/hooks--pre-auto-gc.sample file?
Please don't, as samples are propagated to all newly created repositories.
Chris Packham· Jun 29, 2010, 16:00 UTC · re: Junio C Hamano · lore

Re: [PATCH/RFC] Documentation/git-gc.txt: add reference to githooks

On Tue, Jun 29, 2010 at 8:43 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 6 quoted lines
> Marc Branchaud <marcnarc@xiplink.com> writes:
>
>> How about also adding a templates/hooks--pre-auto-gc.sample file?
>
> Please don't, as samples are propagated to all newly created repositories.
>
OK. I won't add a sample hook.
Junio C Hamano· Jun 29, 2010, 16:26 UTC · re: Chris Packham · lore

Re: [PATCH/RFC] Documentation/git-gc.txt: add reference to githooks

Chris Packham <judge.packham@gmail.com> writes:
> +HOOKS
> +-----
> +This command can run `pre-auto-gc` hook.  See linkgit:githooks[5] for more
> +information.

Hmm. "git gc --auto" does, but "git gc" doesn't, and saying "can run" only adds to the sense of incompleteness of the description here without giving useful information to the reader (iow, the user will have to check the referred-to page anyway). We would need to either remove the first sentence (leaving only "See ... for information") or clarify the first sentence a bit better, I think.

Chris Packham· Jun 29, 2010, 18:16 UTC · re: Junio C Hamano · lore

Re: [PATCH/RFC] Documentation/git-gc.txt: add reference to githooks

On 29/06/10 09:26, Junio C Hamano wrote:
Show 14 quoted lines
> Chris Packham <judge.packham@gmail.com> writes:
>   
>> +HOOKS
>> +-----
>> +This command can run `pre-auto-gc` hook.  See linkgit:githooks[5] for more
>> +information.
>>     
> Hmm.  "git gc --auto" does, but "git gc" doesn't, and saying "can run"
> only adds to the sense of incompleteness of the description here without
> giving useful information to the reader (iow, the user will have to check
> the referred-to page anyway).  We would need to either remove the first
> sentence (leaving only "See ... for information") or clarify the first
> sentence a bit better, I think.
>   
How about

The `git gc --auto` command will run the `pre-auto-gc` hook, if enabled. See linkgit:githooks[5] for more information.

Chris Packham· Jun 30, 2010, 20:41 UTC · re: Chris Packham · lore

[PATCHv2] Documentation/git-gc.txt: add reference to githooks

This advertises the existence of the 'pre-auto-gc' hook and adds a cross reference to where the hook is documented.

Signed-off-by: Chris Packham <judge.packham@gmail.com>
---

I removed the ',if enabled' part from what I suggested on the list. It never did read quite right to me and I think it just adds confusion to what should be a simple sentence.

 Documentation/git-gc.txt |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index a9e0882..315f07e 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -137,6 +137,13 @@ If you are expecting some objects to be collected and they aren't, check
 all of those locations and decide whether it makes sense in your case to
 remove those references.
 
+HOOKS
+-----
+
+The 'git gc --auto' command will run the 'pre-auto-gc' hook.  See
+linkgit:githooks[5] for more information.
+
+
 SEE ALSO
 --------
 linkgit:git-prune[1]
-- 
1.7.1
David Brown· Sep 21, 2010, 18:14 UTC · re: Chris Packham · lore

Re: [PATCH/RFC] Documentation/git-gc.txt: add reference to githooks

Suppose I want to publish some changes to a tree. I have a server available where I can run a git daemon, but for one reason or another I want to force people to use the another git repo as a reference. The reason could be one of bandwidth, or someone who isn't comfortable making all of the other source available. Ideally, someone who already has the other git repo cloned, and just adds mine as a remote wouldn't notice the difference.

Is there a way to do this? I've tried various ways of using alternates to keep the blobs out of the repository I want to export, but the daemon just follows the alternates. If I remove the alternates, I then seem to have a broken repository. Most things I try, at least carry objects for all of the files in the HEAD tree, which most of the time is a large portion of the data.

If there isn't a way of doing this currently, is this something that others would find useful?

Thanks, David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
Chris Packham· Sep 21, 2010, 20:52 UTC · re: David Brown · lore

Re: Allow git remote add but not git clone ( was Re: [PATCH/RFC] Documentation/git-gc.txt: add reference to githooks)

On 21/09/10 11:14, David Brown wrote:
> Subject: Re: [PATCH/RFC] Documentation/git-gc.txt: add reference to githooks

Wow odd thread to pickup. Hopefully someone that knows more than me will notice the change of subject an provide a better answer.

Show 7 quoted lines
> Suppose I want to publish some changes to a tree.  I have a server
> available where I can run a git daemon, but for one reason or another
> I want to force people to use the another git repo as a reference.
> The reason could be one of bandwidth, or someone who isn't comfortable
> making all of the other source available.  Ideally, someone who
> already has the other git repo cloned, and just adds mine as a remote
> wouldn't notice the difference.
Sounds like a reasonable motivation.
> Is there a way to do this?

As far as I know no. The mechanisms that git clone and git remote add/git fetch are fairly generic so I doubt there is a way for the git daemon to know which was run by the user at the other end. Maybe there are other possible solutions outside of git to but a cap the amount of data sent. Doesn't look like there are any hooks on the upload-pack side of git daemon.

> If there isn't a way of doing this currently, is this something that
> others would find useful?
I personally wouldn't but I can see why some people might want this.
David Brown· Sep 21, 2010, 21:01 UTC · re: Chris Packham · lore

Re: Allow git remote add but not git clone ( was Re: [PATCH/RFC] Documentation/git-gc.txt: add reference to githooks)

On Tue, Sep 21, 2010 at 01:52:57PM -0700, Chris Packham wrote:
Show 5 quoted lines
> On 21/09/10 11:14, David Brown wrote:
> > Subject: Re: [PATCH/RFC] Documentation/git-gc.txt: add reference to githooks
> 
> Wow odd thread to pickup. Hopefully someone that knows more than me will
> notice the change of subject an provide a better answer.

Yeah, I sent another message with an entirely new subject and new thread so that hopefully people will see it. This one can just die.

David
Junio C Hamano· Sep 21, 2010, 23:18 UTC · re: David Brown · lore

Re* [PATCH/RFC] Documentation/git-gc.txt: add reference to githooks

David Brown <davidb@codeaurora.org> writes:
Show 14 quoted lines
> Suppose I want to publish some changes to a tree.  I have a server
> available where I can run a git daemon, but for one reason or another
> I want to force people to use the another git repo as a reference.
> The reason could be one of bandwidth, or someone who isn't comfortable
> making all of the other source available.  Ideally, someone who
> already has the other git repo cloned, and just adds mine as a remote
> wouldn't notice the difference.
>
> Is there a way to do this?  I've tried various ways of using
> alternates to keep the blobs out of the repository I want to export,
> but the daemon just follows the alternates.  If I remove the
> alternates, I then seem to have a broken repository.  Most things I
> try, at least carry objects for all of the files in the HEAD tree,
> which most of the time is a large portion of the data.

I've seen people ask for something like this in the past for a few times. Once might have been during GitTogether'08 by you.

I don't think there is a way to do that, though.

Perhaps something like this totally untested patch? The code may be utterly wrong but you should be able to get the idea from the test scripts. Add configuration to the repository for you to declare which objects are prerequiste for pulling from you, with a message to suggest where to grab them from.

I am a bit reluctant to suggest upload-pack to start reading from the repository configuration, though.

 t/t5532-upload-limit.sh |  107 +++++++++++++++++++++++++++++++++++++++++
 upload-pack.c           |  120 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 227 insertions(+), 0 deletions(-)
diff --git a/t/t5532-upload-limit.sh b/t/t5532-upload-limit.sh
new file mode 100755
index 0000000..070594e
--- /dev/null
+++ b/t/t5532-upload-limit.sh
@@ -0,0 +1,107 @@
+#!/bin/sh
+#
+# Copyright (c) 2010 Google Inc.
+#
+
+test_description='git upload-pack honoring clonelimit configuration'
+
+. ./test-lib.sh
+
+grow () {
+	for a
+	do
+		echo "$a" >file &&
+		git add file &&
+		git commit -m "$a" || exit
+	done
+}
+
+setup_clone () {
+	git clone "file://$(pwd)/src" "$1" &&
+	(
+		cd "$1" &&
+		git rev-parse --verify "$2" >actual
+	) &&
+	test_cmp src/expect "$1/actual"
+}
+
+test_expect_success 'setup' '
+	mkdir src &&
+	(
+		cd src &&
+		git init &&
+		grow a b c &&
+		git rev-parse --verify master >expect
+	) &&
+	setup_clone dst-0 master &&
+	setup_clone dst-1 master &&
+	(
+		cd src &&
+		grow d e &&
+		git tag -a -m mark mark &&
+		git rev-parse --verify mark >expect
+	) &&
+	setup_clone dst-2 mark &&
+	setup_clone dst-3 mark &&
+	(
+		cd src &&
+		grow f g h &&
+		git tag -a -m tip tip &&
+		git rev-parse --verify tip >expect
+	)
+'
+
+test_expect_success 'baseline - no limitation in fetch' '
+	(
+		cd dst-0 &&
+		git fetch &&
+		git rev-parse --verify tip >actual
+	) &&
+	test_cmp src/expect dst-0/actual
+'
+
+test_expect_success 'clone refused when limitation is set' '
+	(
+		cd src &&
+		git config clonelimit.mark.message "go away"
+	) &&
+	test_must_fail git clone "file://$(pwd)/src" dst-4 &&
+	! test -d dst-4
+'
+
+test_expect_success 'fetch refused when limitation is unmet' '
+	(
+		cd dst-1 &&
+		test_must_fail git fetch &&
+		test_must_fail git rev-parse --verify tip
+	)
+'
+
+test_expect_success 'fetch works when limitation is met' '
+	(
+		cd src &&
+		git config clonelimit.mark.message "go away"
+	) &&
+	(
+		cd dst-2 &&
+		git fetch &&
+		git rev-parse --verify tip >actual
+	) &&
+	test_cmp src/expect dst-2/actual
+'
+
+test_expect_success 'missing tag is not a limitation violation' '
+	(
+		cd src &&
+		git config clonelimit.mark.message "go away"
+	) &&
+	(
+		cd dst-3 &&
+		git tag -d mark &&
+		git fetch &&
+		git rev-parse --verify tip >actual
+	) &&
+	test_cmp src/expect dst-3/actual
+'
+
+test_done
diff --git a/upload-pack.c b/upload-pack.c
index 92f9530..9d4a367 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -655,6 +655,124 @@ static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag
 	return 0;
 }
 
+/*
+ * Some repositories may not want to allow a full clone, and
+ * want users to first fetch from other repositories with
+ * better connection.  By having a configuration variable like
+ * this:
+ *
+ * [clonelimit "v0.99"]
+ *   message = go to git://git.kernel.org/pub/scm/git/...
+ *
+ * a fetch request by a fetcher that does not have the named commit
+ * is denied with the given message.
+ */
+struct clone_limit {
+	struct clone_limit *next;
+	struct commit *commit;
+	char *ref; /* points at the tail of msg to store symbolic ref */
+	char msg[FLEX_ARRAY]; /* message and more */
+};
+
+static int check_clone_limit(const char *var, const char *value, void *cb_)
+{
+	int msglen, reflen;
+	const char *lastdot;
+	struct clone_limit **clp = cb_;
+	struct clone_limit *limit;
+	unsigned char sha1[20];
+
+	if (prefixcmp(var, "clonelimit."))
+		return 0;
+
+	if (debug_fd) {
+		write_str_in_full(debug_fd, "config: ");
+		write_str_in_full(debug_fd, var);
+		write_str_in_full(debug_fd, " = <");
+		write_str_in_full(debug_fd, value);
+		write_str_in_full(debug_fd, ">\n");
+	}
+
+	var += 11; /* skip "clonelimit." */
+	lastdot = strrchr(var, '.');
+	reflen = lastdot - var;
+	if (reflen < 0 || memcmp(var + reflen, ".message", 9))
+		return 0; /* not our variable */
+
+	/*
+	 * The remainder will ignore a malformed entry; we might
+	 * want to abort the whole operation.  I dunno.
+	 */
+	if (!value)
+		return 0;
+	msglen = strlen(value) + 1;
+	limit = xmalloc(sizeof(*limit) + msglen + reflen + 1);
+	memcpy(limit->msg, value, msglen);
+	limit->ref = limit->msg + msglen;
+	memcpy(limit->ref, var, reflen);
+	limit->ref[reflen] = '\0';
+	if (get_sha1(limit->ref, sha1)) {
+		free(limit);
+		return 0;
+	}
+	limit->commit = lookup_commit_reference_gently(sha1, 0);
+	if (!limit->commit) {
+		free(limit);
+		return 0;
+	}
+	limit->next = *clp;
+	*clp = limit;
+	return 0;
+}
+
+static int limit_served_history(void)
+{
+	int has_missing, i, n;
+	struct clone_limit *clone_limit = NULL;
+	struct clone_limit *cl;
+	struct commit **twos = NULL;
+	struct commit_list *l;
+
+	git_config(check_clone_limit, &clone_limit);
+	if (!clone_limit)
+		return 0;
+
+	twos = xcalloc(have_obj.nr, sizeof(*twos));
+	for (i = n = 0; i < have_obj.nr; i++) {
+		struct object *o = have_obj.objects[i].item;
+		struct commit *have = lookup_commit_reference_gently(o->sha1, 0);
+		if (!have)
+			continue;
+		twos[n++] = have;
+	}
+
+	has_missing = 0;
+	for (cl = clone_limit; cl; cl = cl->next) {
+		int seen = 0;
+		l = get_merge_bases_many(cl->commit, n, twos, 1);
+		while (l) {
+			struct commit_list *next = l->next;
+			if (!hashcmp(l->item->object.sha1, cl->commit->object.sha1))
+				seen = 1;
+			free(l);
+			l = next;
+		}
+		if (!seen) {
+			has_missing = 1;
+			error("you do not have object '%s'; %s",
+			      cl->ref, cl->msg);
+		}
+	}
+
+	while (clone_limit) {
+		struct clone_limit *next = clone_limit->next;
+		free(clone_limit);
+		clone_limit = next;
+	}
+	free(twos);
+	return has_missing;
+}
+
 static void upload_pack(void)
 {
 	if (advertise_refs || !stateless_rpc) {
@@ -672,6 +790,8 @@ static void upload_pack(void)
 	receive_needs();
 	if (want_obj.nr) {
 		get_common_commits();
+		if (limit_served_history())
+			die("git upload-pack: missing prerequisites");
 		create_pack_file();
 	}
 }
Eric Raible· Jun 28, 2010, 18:58 UTC · re: Chris Packham · lore

Re: notify alternative to auto gc?

Chris Packham <judge.packham <at> gmail.com> writes:
Show 7 quoted lines
> So a hook like
> 
>   #! /bin/sh
>   echo "repository needs git gc"
>   exit 1
> 
> Should cause the auto gc to be skipped.

Except wouldn't you also need a mechanism to allow an explicit gc to actually proceed?

Jacob Helwig· Jun 28, 2010, 19:02 UTC · re: Eric Raible · lore

Re: notify alternative to auto gc?

On Mon, Jun 28, 2010 at 11:58, Eric Raible <raible@gmail.com> wrote:
Show 13 quoted lines
> Chris Packham <judge.packham <at> gmail.com> writes:
>
>> So a hook like
>>
>>   #! /bin/sh
>>   echo "repository needs git gc"
>>   exit 1
>>
>> Should cause the auto gc to be skipped.
>
> Except wouldn't you also need a mechanism
> to allow an explicit gc to actually proceed?
>
Only if you're explicitly calling "git gc --auto" instead of "git gc".
 That hook should only run for "git gc --auto".

← back to recent threads