threads / discuss / 26964

Git exhausts memory.

Subject: Git exhausts memory.

## tl;dr

19 messages between Apr 2, 2011 and Apr 6, 2011.

replies: 18people: 8as markdown or json

Alif Wahid· Apr 2, 2011, 05:01 UTC · lore
Hi there,

I'm using Git v1.7.1 on Ubuntu v10.10 and unfortunately Git seems to regularly exhaust the memory on my machine and fails to compress loose objects and/or collect garbage.

My Intel based dual-core machine has 2 GB of RAM and 4 GB of swap space. I need to track a working tree with a handful of really large tarballs that rarely change and loads of really small text files that change frequently. What I'm seeing is that over time whenever "git gc" runs automatically it fails with the message "fatal: Out of memory, malloc failed". So I've been trying to manually run "git repack -ad --window-memory=1g --max-pack-size=1g" in the hope that Git will not exceed the physical memory. But I still get the same error message :(

As I can't make my repository public, I've attached a simple Python script that generates a ~1.3 GB file containing random integers (takes roughly 10 min. on my machine). Then I run the following four commands and get the out-of-memory failure from "git repack". This is effectively emulating the scenario I have with my repository.

$ git init $ git add ./test_data.dat $ git commit ./test_data.dat -m "Test data." $ git repack -ad --window-memory=1g --max-pack-size=1g Counting objects: 3, done. Delta compression using up to 2 threads. Compressing objects: 100% (2/2), done. fatal: Out of memory, malloc failed

I can't find anything on the wiki about out-of-memory failures. Any info/help would be much appreciated.

Regards
Alif
#! /usr/bin/env python
import sys, os, random
if __name__ == '__main__':
    fbuff = 2**28   # file buffer size in bytes
    fints = 10**8   # number of integers to write
    fsize = 12      # number of digits to write per integer
    
    fname = os.path.splitext(os.path.basename(sys.argv[0]))[0]
    try:
        os.mkdir(fname)
    except OSError:
        pass    # directory already exists
        
    fpath = os.path.join(fname, fname+'.dat')
    fhand = open(fpath, 'w', fbuff)
    
    sys.stdout.write('Writing %d MB to file \'%s\'\n' % (fints*(fsize+1)/10**6, fpath))
    sys.stdout.write('This will take some time, please wait.\n')
    sys.stdout.write('Progress:')
    sys.stdout.flush()
    random.seed(-1)
    fform = '%'+str(fsize)+'d\n'
    for x in xrange(fints): 
        fhand.write(fform % (random.randint(0,fints)))
        if x % (fints/10) == 0 and x > 0:
            sys.stdout.write('%3d/10' % (x/(fints/10))) 
            sys.stdout.flush()
    sys.stdout.write(' 10/10\n')
    sys.stdout.flush()
    fhand.close()
Nicolas Pitre· Apr 2, 2011, 15:05 UTC · re: Alif Wahid · lore

Re: Git exhausts memory.

On Sat, 2 Apr 2011, Alif Wahid wrote:
Show 14 quoted lines
> Hi there,
> 
> I'm using Git v1.7.1 on Ubuntu v10.10 and unfortunately Git seems to
> regularly exhaust the memory on my machine and fails to compress loose
> objects and/or collect garbage.
> 
> My Intel based dual-core machine has 2 GB of RAM and 4 GB of swap
> space. I need to track a working tree with a handful of really large
> tarballs that rarely change and loads of really small text files that
> change frequently. What I'm seeing is that over time whenever "git gc"
> runs automatically it fails with the message "fatal: Out of memory,
> malloc failed". So I've been trying to manually run "git repack -ad
> --window-memory=1g --max-pack-size=1g" in the hope that Git will not
> exceed the physical memory. But I still get the same error message :(
Don't use --max-pack-size.  That won't help here.
How large are those tar files?
Nicolas
Alif Wahid· Apr 3, 2011, 09:15 UTC · re: Nicolas Pitre · lore

Re: Git exhausts memory.

Hi Nicolas,
On 3 April 2011 02:05, Nicolas Pitre <nico@fluxnic.net> wrote:
> Don't use --max-pack-size.  That won't help here.

I've tried only --window-memory with different values and they all failed. It seems to me as though this option is simply ignored or non-existent.

> How large are those tar files?

The tar files aggregate to just under 2 GB and my complete working tree is around 3 GB. Whenever I run git-gc or git-repack they seem to reach a virtual mem. footprint of roughly 2.5 GB over the course of 10 minutes and then fail with the out-of-memory error.

Alif
Nicolas Pitre· Apr 3, 2011, 15:18 UTC · re: Alif Wahid · lore

Re: Git exhausts memory.

On Sun, 3 Apr 2011, Alif Wahid wrote:
Show 9 quoted lines
> Hi Nicolas,
> 
> On 3 April 2011 02:05, Nicolas Pitre <nico@fluxnic.net> wrote:
> 
> > Don't use --max-pack-size.  That won't help here.
> 
> I've tried only --window-memory with different values and they all
> failed. It seems to me as though this option is simply ignored or
> non-existent.

It is not ignored, but there are situations where there are problem making it effective, especially if a few files are very large.

> > How large are those tar files?
> 
> The tar files aggregate to just under 2 GB and my complete working
> tree is around 3 GB.
What about the individual size for those files?

Something you can try is to simply tell Git not to attempt any delta compression on those tar files using gitattributes (see the man page of the same name).

Nicolas
Alif Wahid· Apr 4, 2011, 12:52 UTC · re: Nicolas Pitre · lore

Re: Git exhausts memory.

Hi Nicolas,
On 4 April 2011 01:18, Nicolas Pitre <nico@fluxnic.net> wrote:
Show 5 quoted lines
>
> Something you can try is to simply tell Git not to attempt any delta
> compression on those tar files using gitattributes (see the man page of
> the same name).
>

Seems to have worked. Both git-gc and git-repack appear to be less memory hungry now and do actually run to completion without failure.

Thanks for your help.
Cheers
Alif
Nguyen Thai Ngoc Duy· Apr 4, 2011, 14:57 UTC · re: Alif Wahid · lore

Re: Git exhausts memory.

On Mon, Apr 4, 2011 at 7:52 PM, Alif Wahid <alif.wahid@gmail.com> wrote:
Show 7 quoted lines
> Hi Nicolas,
>
> On 4 April 2011 01:18, Nicolas Pitre <nico@fluxnic.net> wrote:
>>
>> Something you can try is to simply tell Git not to attempt any delta
>> compression on those tar files using gitattributes (see the man page of
>> the same name).

Should we change the default to not delta if a blob exceeds predefined limit (say 128M)? People who deliberately wants to delta them can still set delta attr. 1.8.0 material maybe?

> Seems to have worked. Both git-gc and git-repack appear to be less
> memory hungry now and do actually run to completion without failure.
>
> Thanks for your help.
-- 
Duy
David Fries· Apr 5, 2011, 02:22 UTC · re: Nguyen Thai Ngoc Duy · lore

Re: Git exhausts memory.

On Mon, Apr 04, 2011 at 09:57:01PM +0700, Nguyen Thai Ngoc Duy wrote:
Show 12 quoted lines
> On Mon, Apr 4, 2011 at 7:52 PM, Alif Wahid <alif.wahid@gmail.com> wrote:
> > Hi Nicolas,
> >
> > On 4 April 2011 01:18, Nicolas Pitre <nico@fluxnic.net> wrote:
> >>
> >> Something you can try is to simply tell Git not to attempt any delta
> >> compression on those tar files using gitattributes (see the man page of
> >> the same name).
> 
> Should we change the default to not delta if a blob exceeds predefined
> limit (say 128M)? People who deliberately wants to delta them can
> still set delta attr. 1.8.0 material maybe?

I think it would be better to define it in terms of available memory. Something like the minimum of system memory or address space, and delta up to X amount of that (it might be good to leave off swap to reduce trashing). There has to be a better way than a straight 128MB default.

The number which works on my 8GB desktop is going to kill the computer in the trunk of my car with 48MB of ram. I've actually seen a 700 MB repository fail with `git-gc --aggressive` on a system with 4GB of ram because it ran out of memory, it only worked by leaving off the --aggressive option.

Show 10 quoted lines
> > Seems to have worked. Both git-gc and git-repack appear to be less
> > memory hungry now and do actually run to completion without failure.
> >
> > Thanks for your help.
> -- 
> Duy
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
David Fries <david@fries.net>    PGP pub CB1EE8F0
http://fries.net/~david/
Alif Wahid· Apr 5, 2011, 04:35 UTC · re: David Fries · lore

Re: Git exhausts memory.

Hi everyone,
On 5 April 2011 12:22, David Fries <david@fries.net> wrote:
Show 25 quoted lines
> On Mon, Apr 04, 2011 at 09:57:01PM +0700, Nguyen Thai Ngoc Duy wrote:
>> On Mon, Apr 4, 2011 at 7:52 PM, Alif Wahid <alif.wahid@gmail.com> wrote:
>> > Hi Nicolas,
>> >
>> > On 4 April 2011 01:18, Nicolas Pitre <nico@fluxnic.net> wrote:
>> >>
>> >> Something you can try is to simply tell Git not to attempt any delta
>> >> compression on those tar files using gitattributes (see the man page of
>> >> the same name).
>>
>> Should we change the default to not delta if a blob exceeds predefined
>> limit (say 128M)? People who deliberately wants to delta them can
>> still set delta attr. 1.8.0 material maybe?
>
> I think it would be better to define it in terms of available memory.
> Something like the minimum of system memory or address space, and
> delta up to X amount of that (it might be good to leave off swap to
> reduce trashing).  There has to be a better way than a straight 128MB
> default.
>
> The number which works on my 8GB desktop is going to kill the computer
> in the trunk of my car with 48MB of ram.  I've actually seen a 700 MB
> repository fail with `git-gc --aggressive` on a system with 4GB of ram
> because it ran out of memory, it only worked by leaving off the
> --aggressive option.

It seems to me that if "git init" creates a $GIT_DIR/info/attributes file by default with a line like "*.gz -delta", then that will disable the memory intensive deltra compression plumbing for those special cases where people need to track gzip archives (similarly another line "*.bz2 -delta" for bzip2 archives and so on). Since these files can't supposedly be compressed much more, I think Git ought to have a default heuristic to not attempt any compression on them.

Cheers
Alif
Nguyen Thai Ngoc Duy· Apr 5, 2011, 11:13 UTC · re: Alif Wahid · lore

Re: Git exhausts memory.

On Tue, Apr 5, 2011 at 11:35 AM, Alif Wahid <alif.wahid@gmail.com> wrote:
Show 7 quoted lines
> It seems to me that if "git init" creates a $GIT_DIR/info/attributes
> file by default with a line like "*.gz -delta", then that will disable
> the memory intensive deltra compression plumbing for those special
> cases where people need to track gzip archives (similarly another line
> "*.bz2 -delta" for bzip2 archives and so on). Since these files can't
> supposedly be compressed much more, I think Git ought to have a
> default heuristic to not attempt any compression on them.

I was thinking of very similar thing on my ride home. But I selected files on size, not extension. With the (hopefully coming soon) introduction of pathspec magic specifier [1], we can teach git-attr to express "files that have size in a range [a,b]" (either a or b can be infinite). The rest is like yours: applying -delta on selected files then put such a rule with a default range in default template.

[1] http://thread.gmane.org/gmane.comp.version-control.git/169813/focus=169844
-- 
Duy
Alif Wahid· Apr 5, 2011, 11:26 UTC · re: Nguyen Thai Ngoc Duy · lore

Re: Git exhausts memory.

On 5 April 2011 21:13, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
Show 17 quoted lines
> On Tue, Apr 5, 2011 at 11:35 AM, Alif Wahid <alif.wahid@gmail.com> wrote:
>> It seems to me that if "git init" creates a $GIT_DIR/info/attributes
>> file by default with a line like "*.gz -delta", then that will disable
>> the memory intensive deltra compression plumbing for those special
>> cases where people need to track gzip archives (similarly another line
>> "*.bz2 -delta" for bzip2 archives and so on). Since these files can't
>> supposedly be compressed much more, I think Git ought to have a
>> default heuristic to not attempt any compression on them.
>
> I was thinking of very similar thing on my ride home. But I selected
> files on size, not extension. With the (hopefully coming soon)
> introduction of pathspec magic specifier [1], we can teach git-attr to
> express "files that have size in a range [a,b]" (either a or b can be
> infinite). The rest is like yours: applying -delta on selected files
> then put such a rule with a default range in default template.
>
> [1] http://thread.gmane.org/gmane.comp.version-control.git/169813/focus=169844
Yeah, makes sense.

I also noticed the following thread regarding big file support. Most of the details there are related to this issue as well.

http://thread.gmane.org/gmane.comp.version-control.git/170649/focus=170649
Alif
Holger Hellmuth· Apr 5, 2011, 16:48 UTC · re: Nguyen Thai Ngoc Duy · lore

Re: Git exhausts memory.

On 04.04.2011 16:57, Nguyen Thai Ngoc Duy wrote:
Show 12 quoted lines
> On Mon, Apr 4, 2011 at 7:52 PM, Alif Wahid<alif.wahid@gmail.com>  wrote:
>> Hi Nicolas,
>>
>> On 4 April 2011 01:18, Nicolas Pitre<nico@fluxnic.net>  wrote:
>>>
>>> Something you can try is to simply tell Git not to attempt any delta
>>> compression on those tar files using gitattributes (see the man page of
>>> the same name).
>
> Should we change the default to not delta if a blob exceeds predefined
> limit (say 128M)? People who deliberately wants to delta them can
> still set delta attr. 1.8.0 material maybe?
Isn't this already done with the config variable core.bigFileThreshold ?

documentation says: "Files larger than this size are stored deflated, without attempting delta compression. ... Default is 512 MiB on all platforms."

Shawn Pearce· Apr 5, 2011, 17:06 UTC · re: Holger Hellmuth · lore

Re: Git exhausts memory.

On Tue, Apr 5, 2011 at 12:48, Holger Hellmuth <hellmuth@ira.uka.de> wrote:
Show 11 quoted lines
> On 04.04.2011 16:57, Nguyen Thai Ngoc Duy wrote:
>>
>> Should we change the default to not delta if a blob exceeds predefined
>> limit (say 128M)? People who deliberately wants to delta them can
>> still set delta attr. 1.8.0 material maybe?
>
> Isn't this already done with the config variable core.bigFileThreshold ?
>
> documentation says: "Files larger than this size are stored deflated,
> without attempting delta compression. ... Default is 512 MiB on all
> platforms."

This is only implemented inside of fast-import. pack-objects does not honor this variable.

-- 
Shawn.
Junio C Hamano· Apr 5, 2011, 17:44 UTC · re: Shawn Pearce · lore

Re: Git exhausts memory.

Shawn Pearce <spearce@spearce.org> writes:
Show 15 quoted lines
> On Tue, Apr 5, 2011 at 12:48, Holger Hellmuth <hellmuth@ira.uka.de> wrote:
>> On 04.04.2011 16:57, Nguyen Thai Ngoc Duy wrote:
>>>
>>> Should we change the default to not delta if a blob exceeds predefined
>>> limit (say 128M)? People who deliberately wants to delta them can
>>> still set delta attr. 1.8.0 material maybe?
>>
>> Isn't this already done with the config variable core.bigFileThreshold ?
>>
>> documentation says: "Files larger than this size are stored deflated,
>> without attempting delta compression. ... Default is 512 MiB on all
>> platforms."
>
> This is only implemented inside of fast-import. pack-objects does not
> honor this variable.
Do you mean perhaps we should?
 builtin/pack-objects.c |    8 ++++++--
 cache.h                |    1 +
 config.c               |    6 ++++++
 environment.c          |    1 +
 fast-import.c          |    5 -----
 5 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index b0503b2..f402a84 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -1142,8 +1142,12 @@ static void get_object_details(void)
 		sorted_by_offset[i] = objects + i;
 	qsort(sorted_by_offset, nr_objects, sizeof(*sorted_by_offset), pack_offset_sort);
 
-	for (i = 0; i < nr_objects; i++)
-		check_object(sorted_by_offset[i]);
+	for (i = 0; i < nr_objects; i++) {
+		struct object_entry *entry = sorted_by_offset[i];
+		check_object(entry);
+		if (big_file_threshold <= entry->size)
+			entry->no_try_delta = 1;
+	}
 
 	free(sorted_by_offset);
 }
diff --git a/cache.h b/cache.h
index 2674f4c..316d85f 100644
--- a/cache.h
+++ b/cache.h
@@ -573,6 +573,7 @@ extern int core_compression_seen;
 extern size_t packed_git_window_size;
 extern size_t packed_git_limit;
 extern size_t delta_base_cache_limit;
+extern uintmax_t big_file_threshold;
 extern int read_replace_refs;
 extern int fsync_object_files;
 extern int core_preload_index;
diff --git a/config.c b/config.c
index 0abcada..d06fb19 100644
--- a/config.c
+++ b/config.c
@@ -567,6 +567,12 @@ static int git_default_core_config(const char *var, const char *value)
 		return 0;
 	}
 
+	if (!strcmp(var, "core.bigfilethreshold")) {
+		long n = git_config_int(var, value);
+		big_file_threshold = 0 < n ? n : 0;
+		return 0;
+	}
+
 	if (!strcmp(var, "core.packedgitlimit")) {
 		packed_git_limit = git_config_int(var, value);
 		return 0;
diff --git a/environment.c b/environment.c
index f4549d3..3d1ab51 100644
--- a/environment.c
+++ b/environment.c
@@ -35,6 +35,7 @@ int fsync_object_files;
 size_t packed_git_window_size = DEFAULT_PACKED_GIT_WINDOW_SIZE;
 size_t packed_git_limit = DEFAULT_PACKED_GIT_LIMIT;
 size_t delta_base_cache_limit = 16 * 1024 * 1024;
+uintmax_t big_file_threshold = 512 * 1024 * 1024;
 const char *pager_program;
 int pager_use_color = 1;
 const char *editor_program;
diff --git a/fast-import.c b/fast-import.c
index 65d65bf..3e4e655 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -274,7 +274,6 @@ struct recent_command {
 /* Configured limits on output */
 static unsigned long max_depth = 10;
 static off_t max_packsize;
-static uintmax_t big_file_threshold = 512 * 1024 * 1024;
 static int force_update;
 static int pack_compression_level = Z_DEFAULT_COMPRESSION;
 static int pack_compression_seen;
@@ -3206,10 +3205,6 @@ static int git_pack_config(const char *k, const char *v, void *cb)
 		max_packsize = git_config_ulong(k, v);
 		return 0;
 	}
-	if (!strcmp(k, "core.bigfilethreshold")) {
-		long n = git_config_int(k, v);
-		big_file_threshold = 0 < n ? n : 0;
-	}
 	return git_default_config(k, v, cb);
 }
 
Nicolas Pitre· Apr 5, 2011, 20:56 UTC · re: Junio C Hamano · lore

Re: Git exhausts memory.

On Tue, 5 Apr 2011, Junio C Hamano wrote:
Show 19 quoted lines
> Shawn Pearce <spearce@spearce.org> writes:
> 
> > On Tue, Apr 5, 2011 at 12:48, Holger Hellmuth <hellmuth@ira.uka.de> wrote:
> >> On 04.04.2011 16:57, Nguyen Thai Ngoc Duy wrote:
> >>>
> >>> Should we change the default to not delta if a blob exceeds predefined
> >>> limit (say 128M)? People who deliberately wants to delta them can
> >>> still set delta attr. 1.8.0 material maybe?
> >>
> >> Isn't this already done with the config variable core.bigFileThreshold ?
> >>
> >> documentation says: "Files larger than this size are stored deflated,
> >> without attempting delta compression. ... Default is 512 MiB on all
> >> platforms."
> >
> > This is only implemented inside of fast-import. pack-objects does not
> > honor this variable.
> 
> Do you mean perhaps we should?
Yes.
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Show 91 quoted lines
>  builtin/pack-objects.c |    8 ++++++--
>  cache.h                |    1 +
>  config.c               |    6 ++++++
>  environment.c          |    1 +
>  fast-import.c          |    5 -----
>  5 files changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> index b0503b2..f402a84 100644
> --- a/builtin/pack-objects.c
> +++ b/builtin/pack-objects.c
> @@ -1142,8 +1142,12 @@ static void get_object_details(void)
>  		sorted_by_offset[i] = objects + i;
>  	qsort(sorted_by_offset, nr_objects, sizeof(*sorted_by_offset), pack_offset_sort);
>  
> -	for (i = 0; i < nr_objects; i++)
> -		check_object(sorted_by_offset[i]);
> +	for (i = 0; i < nr_objects; i++) {
> +		struct object_entry *entry = sorted_by_offset[i];
> +		check_object(entry);
> +		if (big_file_threshold <= entry->size)
> +			entry->no_try_delta = 1;
> +	}
>  
>  	free(sorted_by_offset);
>  }
> diff --git a/cache.h b/cache.h
> index 2674f4c..316d85f 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -573,6 +573,7 @@ extern int core_compression_seen;
>  extern size_t packed_git_window_size;
>  extern size_t packed_git_limit;
>  extern size_t delta_base_cache_limit;
> +extern uintmax_t big_file_threshold;
>  extern int read_replace_refs;
>  extern int fsync_object_files;
>  extern int core_preload_index;
> diff --git a/config.c b/config.c
> index 0abcada..d06fb19 100644
> --- a/config.c
> +++ b/config.c
> @@ -567,6 +567,12 @@ static int git_default_core_config(const char *var, const char *value)
>  		return 0;
>  	}
>  
> +	if (!strcmp(var, "core.bigfilethreshold")) {
> +		long n = git_config_int(var, value);
> +		big_file_threshold = 0 < n ? n : 0;
> +		return 0;
> +	}
> +
>  	if (!strcmp(var, "core.packedgitlimit")) {
>  		packed_git_limit = git_config_int(var, value);
>  		return 0;
> diff --git a/environment.c b/environment.c
> index f4549d3..3d1ab51 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -35,6 +35,7 @@ int fsync_object_files;
>  size_t packed_git_window_size = DEFAULT_PACKED_GIT_WINDOW_SIZE;
>  size_t packed_git_limit = DEFAULT_PACKED_GIT_LIMIT;
>  size_t delta_base_cache_limit = 16 * 1024 * 1024;
> +uintmax_t big_file_threshold = 512 * 1024 * 1024;
>  const char *pager_program;
>  int pager_use_color = 1;
>  const char *editor_program;
> diff --git a/fast-import.c b/fast-import.c
> index 65d65bf..3e4e655 100644
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -274,7 +274,6 @@ struct recent_command {
>  /* Configured limits on output */
>  static unsigned long max_depth = 10;
>  static off_t max_packsize;
> -static uintmax_t big_file_threshold = 512 * 1024 * 1024;
>  static int force_update;
>  static int pack_compression_level = Z_DEFAULT_COMPRESSION;
>  static int pack_compression_seen;
> @@ -3206,10 +3205,6 @@ static int git_pack_config(const char *k, const char *v, void *cb)
>  		max_packsize = git_config_ulong(k, v);
>  		return 0;
>  	}
> -	if (!strcmp(k, "core.bigfilethreshold")) {
> -		long n = git_config_int(k, v);
> -		big_file_threshold = 0 < n ? n : 0;
> -	}
>  	return git_default_config(k, v, cb);
>  }
>  
> 
Junio C Hamano· Apr 5, 2011, 22:16 UTC · re: Nicolas Pitre · lore

Re: Git exhausts memory.

Nicolas Pitre <nico@fluxnic.net> writes:
Show 8 quoted lines
>> > This is only implemented inside of fast-import. pack-objects does not
>> > honor this variable.
>> 
>> Do you mean perhaps we should?
>
> Yes.
>
> Acked-by: Nicolas Pitre <nico@fluxnic.net>

I actually was somewhat unhappy to use uintmax_t type in the public header for some reason I cannot quite explain (perhaps religious), and was hoping somebody with more sanity than myself would stop me or show me a better way.

Show 12 quoted lines
>> diff --git a/cache.h b/cache.h
>> index 2674f4c..316d85f 100644
>> --- a/cache.h
>> +++ b/cache.h
>> @@ -573,6 +573,7 @@ extern int core_compression_seen;
>>  extern size_t packed_git_window_size;
>>  extern size_t packed_git_limit;
>>  extern size_t delta_base_cache_limit;
>> +extern uintmax_t big_file_threshold;
>>  extern int read_replace_refs;
>>  extern int fsync_object_files;
>>  extern int core_preload_index;
Shawn Pearce· Apr 5, 2011, 22:19 UTC · re: Junio C Hamano · lore

Re: Git exhausts memory.

On Tue, Apr 5, 2011 at 18:16, Junio C Hamano <gitster@pobox.com> wrote:
Show 15 quoted lines
> Nicolas Pitre <nico@fluxnic.net> writes:
>
>>> > This is only implemented inside of fast-import. pack-objects does not
>>> > honor this variable.
>>>
>>> Do you mean perhaps we should?
>>
>> Yes.
>>
>> Acked-by: Nicolas Pitre <nico@fluxnic.net>
>
> I actually was somewhat unhappy to use uintmax_t type in the public header
> for some reason I cannot quite explain (perhaps religious), and was hoping
> somebody with more sanity than myself would stop me or show me a better
> way.

unsigned long? Without even looking at the source, I bet that is the type used by pack-objects for the size member that you are comparing against.

-- 
Shawn.
Nicolas Pitre· Apr 6, 2011, 00:34 UTC · re: Junio C Hamano · lore

Re: Git exhausts memory.

On Tue, 5 Apr 2011, Junio C Hamano wrote:
Show 15 quoted lines
> Nicolas Pitre <nico@fluxnic.net> writes:
> 
> >> > This is only implemented inside of fast-import. pack-objects does not
> >> > honor this variable.
> >> 
> >> Do you mean perhaps we should?
> >
> > Yes.
> >
> > Acked-by: Nicolas Pitre <nico@fluxnic.net>
> 
> I actually was somewhat unhappy to use uintmax_t type in the public header
> for some reason I cannot quite explain (perhaps religious), and was hoping
> somebody with more sanity than myself would stop me or show me a better
> way.

Just use unsigned long. Everywhere we have object size, it is stored as unsigned long.

Nicolas
Jay Soffian· Apr 6, 2011, 15:51 UTC · re: Junio C Hamano · lore

Re: Git exhausts memory.

On Tue, Apr 5, 2011 at 1:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 6 quoted lines
>  builtin/pack-objects.c |    8 ++++++--
>  cache.h                |    1 +
>  config.c               |    6 ++++++
>  environment.c          |    1 +
>  fast-import.c          |    5 -----
>  5 files changed, 14 insertions(+), 7 deletions(-)
This will be white-spaced damaged by Gmail, but anyway:
diff --git i/Documentation/config.txt w/Documentation/config.txt
index 750c86d..91aa9be 100644
--- i/Documentation/config.txt
+++ w/Documentation/config.txt
@@ -443,7 +443,6 @@ be delta compressed, but larger binary media files won't be.
 +
 Common unit suffixes of 'k', 'm', or 'g' are supported.
 +
-Currently only linkgit:git-fast-import[1] honors this setting.

 core.excludesfile::
 	In addition to '.gitignore' (per-directory) and


j.

← back to recent threads