Hi,
If 'git rebase origin/master' dies with an out of memory error
(probably due to a few of large binary files in the repository, the
largest being ~300MB and ~1GB in total in one directory), which
settings should be tweaked and how to get rid of the problem? I
tried...
[pack]
threads = 1
windowMemory = 64M
packSizeLimit = 512M
...based on some suggestions in the net but that was of no help.
I'm using git 1.7.5.1 in Cygwin and I also tried the latest master
branch version (which behaved identically).
--
Hannu
Am 26.10.2011 11:21, schrieb Hannu Koivisto:
If 'git rebase origin/master' dies with an out of memory error
(probably due to a few of large binary files in the repository, the
largest being ~300MB and ~1GB in total in one directory), which
settings should be tweaked and how to get rid of the problem? I
tried...
Try 'git rebase -m origin/master'. Without -m, rebase uses
format-patch+am, i.e., assuming there are changes to the binary files
that are to be rebased, a binary patch file would have to be generated
and applied later. This is very likely where git bails out.
-- Hannes
Johannes Sixt [off-list ref] writes:
Am 26.10.2011 11:21, schrieb Hannu Koivisto:
quoted
If 'git rebase origin/master' dies with an out of memory error
(probably due to a few of large binary files in the repository, the
Try 'git rebase -m origin/master'. Without -m, rebase uses
format-patch+am, i.e., assuming there are changes to the binary files
that are to be rebased, a binary patch file would have to be generated
and applied later. This is very likely where git bails out.
Thanks, -m seems to help, even though the large binary files are
not touched by the rebased commits (instead, they are touched by
the commits on top of which I'm rebasing).
From the documentation I can't figure out any reason why one
wouldn't always want to use -m. Why is it not the default? I
think it's pretty much impossible for ordinary users to figure out
that they need -m in a situation like this.
--
Hannu