On Wed, Mar 18, 2015 at 9:58 PM, John Keeping j...@keeping.me.uk wrote:
On Wed, Mar 18, 2015 at 09:41:59PM +0700, Duy Nguyen wrote:
On Wed, Mar 18, 2015 at 9:33 PM, Duy Nguyen pclo...@gmail.com wrote:
If not, I made some mistake in analyzing this and we'll start again.
I did make one
Hello,
I have a local folder with the git-repository (so that its .git/config
contains ([remote origin]\n url = git://github.com/git/git.git\nfetch
= +refs/heads/*:refs/remotes/origin/* )
I do there git pull.
Usually the output is
Already up to date
but since today it prints
Auto
Hello,
# git gc --auto
Auto packing the repository in background for optimum performance.
See git help gc for manual housekeeping.
and calls in the background:
25618 1 0 32451 884 1 14:20 ?00:00:00 git gc --auto
25639 25618 51 49076 49428 0 14:20 ?00:00:07 git prune
On Wed, Mar 18, 2015 at 9:33 PM, Duy Nguyen pclo...@gmail.com wrote:
If not, I made some mistake in analyzing this and we'll start again.
I did make one mistake, the first gc should have reduced the number
of loose objects to zero. Why didn't it.? I'll come back to this
tomorrow if nobody finds
Hello Duy,
#ls .git/objects/17/* | wc -l
30
30 * 256 = 7 680 6 700
And now? Do I have to run git gc --aggressive ?
Kind regards
Dilian
On 18.03.2015 15:33, Duy Nguyen wrote:
On Wed, Mar 18, 2015 at 9:23 PM, Дилян Палаузов
dilyan.palau...@aegee.org wrote:
Hello,
# git gc --auto
Auto
On Wed, Mar 18, 2015 at 8:53 PM, Дилян Палаузов
dilyan.palau...@aegee.org wrote:
Hello,
I have a local folder with the git-repository (so that its .git/config
contains ([remote origin]\nurl = git://github.com/git/git.git\nfetch =
+refs/heads/*:refs/remotes/origin/* )
I do there git
On Wed, Mar 18, 2015 at 9:23 PM, Дилян Палаузов
dilyan.palau...@aegee.org wrote:
Hello,
# git gc --auto
Auto packing the repository in background for optimum performance.
See git help gc for manual housekeeping.
and calls in the background:
25618 1 0 32451 884 1 14:20 ?
On Wed, Mar 18, 2015 at 09:41:59PM +0700, Duy Nguyen wrote:
On Wed, Mar 18, 2015 at 9:33 PM, Duy Nguyen pclo...@gmail.com wrote:
If not, I made some mistake in analyzing this and we'll start again.
I did make one mistake, the first gc should have reduced the number
of loose objects to zero.
On Thu, Mar 19, 2015 at 07:31:48AM +0700, Duy Nguyen wrote:
Or we could count/estimate the number of loose objects again after
repack/prune. Then we can maybe have a way to prevent the next gc that
we know will not improve the situation anyway. One option is pack
unreachable objects in the
On Wed, Mar 18, 2015 at 09:27:22PM -0400, Jeff King wrote:
On Thu, Mar 19, 2015 at 07:31:48AM +0700, Duy Nguyen wrote:
Or we could count/estimate the number of loose objects again after
repack/prune. Then we can maybe have a way to prevent the next gc that
we know will not improve the
On Wed, Mar 18, 2015 at 6:27 PM, Jeff King p...@peff.net wrote:
Keeping a file that says I ran gc at time T, and there were still N
objects left over is probably the best bet. When the next gc --auto
runs, if T is recent enough, subtract N from the estimated number of
objects. I'm not sure of
On Thu, Mar 19, 2015 at 4:04 AM, Jeff King p...@peff.net wrote:
On Wed, Mar 18, 2015 at 02:58:15PM +, John Keeping wrote:
On Wed, Mar 18, 2015 at 09:41:59PM +0700, Duy Nguyen wrote:
On Wed, Mar 18, 2015 at 9:33 PM, Duy Nguyen pclo...@gmail.com wrote:
If not, I made some mistake in
On Wed, Mar 18, 2015 at 07:27:46PM -0700, Junio C Hamano wrote:
I guess leaving a bunch of loose objects around longer than necessary
isn't the end of the world. It wastes space, but it does not actively
make the rest of git slower (whereas having a large number of packs does
impact
On Thu, Mar 19, 2015 at 12:14:53AM -0400, Jeff King wrote:
On Thu, Mar 19, 2015 at 11:01:17AM +0900, Mike Hommey wrote:
I don't think packing the unreachables is a good plan. They just end up
accumulating then, and they never expire, because we keep refreshing
their mtime at each pack
On Thu, Mar 19, 2015 at 11:15:19AM +0700, Duy Nguyen wrote:
On Thu, Mar 19, 2015 at 8:27 AM, Jeff King p...@peff.net wrote:
Keeping a file that says I ran gc at time T, and there were still N
objects left over is probably the best bet. When the next gc --auto
runs, if T is recent enough,
On Thu, Mar 19, 2015 at 11:20 AM, Jeff King p...@peff.net wrote:
On Thu, Mar 19, 2015 at 11:15:19AM +0700, Duy Nguyen wrote:
On Thu, Mar 19, 2015 at 8:27 AM, Jeff King p...@peff.net wrote:
Keeping a file that says I ran gc at time T, and there were still N
objects left over is probably the
On Thu, Mar 19, 2015 at 11:29:57AM +0700, Duy Nguyen wrote:
That omits the N objects left over information. Which I think may be
useful, because otherwise the rule is basically don't do another gc at
all for X time units. That's OK for most use, but it has its own corner
cases.
True.
On Thu, Mar 19, 2015 at 11:01:17AM +0900, Mike Hommey wrote:
I don't think packing the unreachables is a good plan. They just end up
accumulating then, and they never expire, because we keep refreshing
their mtime at each pack (unless you pack them once and then leave them
to expire, but
On Thu, Mar 19, 2015 at 8:27 AM, Jeff King p...@peff.net wrote:
Keeping a file that says I ran gc at time T, and there were still N
objects left over is probably the best bet. When the next gc --auto
runs, if T is recent enough, subtract N from the estimated number of
objects. I'm not sure of
On Wed, Mar 18, 2015 at 02:58:15PM +, John Keeping wrote:
On Wed, Mar 18, 2015 at 09:41:59PM +0700, Duy Nguyen wrote:
On Wed, Mar 18, 2015 at 9:33 PM, Duy Nguyen pclo...@gmail.com wrote:
If not, I made some mistake in analyzing this and we'll start again.
I did make one mistake,
On Wed, Mar 18, 2015 at 03:48:42PM +0100, Дилян Палаузов wrote:
#ls .git/objects/17/* | wc -l
30
30 * 256 = 7 680 6 700
And now? Do I have to run git gc --aggressive ?
No, aggressive just controls the time we spend on repacking. If the
guess is correct that the objects are kept
21 matches
Mail list logo
