On Wed, Mar 18, 2015 at 9:58 PM, 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 wrote:
>> > If not, I made some mistake in analyzing this and we'll start again.
>>
>> I did make one mistake, the first "gc" should ha
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.
On Thu, Mar 19, 2015 at 11:20 AM, Jeff King 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 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
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
On Thu, Mar 19, 2015 at 11:15:19AM +0700, Duy Nguyen wrote:
> On Thu, Mar 19, 2015 at 8:27 AM, Jeff King 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, subt
On Thu, Mar 19, 2015 at 8:27 AM, Jeff King 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 the ri
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 expir
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
> > impac
On Wed, Mar 18, 2015 at 6:27 PM, Jeff King 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 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
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 Thu, Mar 19, 2015 at 4:04 AM, Jeff King 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 wrote:
>> > > If not, I made some mistake in analyzing this and we'll
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
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 wrote:
> > > If not, I made some mistake in analyzing this and we'll start again.
> >
> > I did make one mistake, the first
On Wed, Mar 18, 2015 at 09:41:59PM +0700, Duy Nguyen wrote:
> On Wed, Mar 18, 2015 at 9:33 PM, Duy Nguyen 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'
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, Дилян Палаузов
wrote:
Hello,
# git gc --auto
Auto packing the repository in
On Wed, Mar 18, 2015 at 9:33 PM, Duy Nguyen 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 out first :)
-
On Wed, Mar 18, 2015 at 9:23 PM, Дилян Палаузов
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 ?00:00:00 git gc -
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 8:53 PM, Дилян Палаузов
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 pull".
>
> Usually t
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 pa
21 matches
Mail list logo
