On Tue, Jul 11, 2017 at 12:35:50AM -0700, Bryan Turner wrote:
> That's a few of the reasons we've switched over. I'd imagine most
> hosting providers take a similarly "hands on" approach to controlling
> their GC. Beyond a certain scale, it seems almost unavoidable. Git
> never has more than a rep
On Mon, Jul 10, 2017 at 9:45 PM, Andreas Krey wrote:
> On Thu, 06 Jul 2017 10:01:05 +, Bryan Turner wrote:
>
>> I also want to add that Bitbucket Server 5.x includes totally
>> rewritten GC handling. 5.0.x automatically disables auto GC in all
>> repositories and manages it explicitly, an
On Thu, Jul 06, 2017 at 10:01:05AM -0700, Bryan Turner wrote:
> I also want to add that Bitbucket Server 5.x includes totally
> rewritten GC handling. 5.0.x automatically disables auto GC in all
> repositories and manages it explicitly, and 5.1.x fully removes use of
> "git gc" in favor of running
[Updating the subject since I think this really is a bug].
On Tue, Jul 11, 2017 at 06:45:53AM +0200, Andreas Krey wrote:
> > I also want to add that Bitbucket Server 5.x includes totally
> > rewritten GC handling. 5.0.x automatically disables auto GC in all
> > repositories and manages it explici
On Thu, 06 Jul 2017 10:01:05 +, Bryan Turner wrote:
> Do you know what version of Bitbucket Server is in use?
We're on the newest 4.x.
...
> - Run "git config gc.auto 0" in
Going that route.
...
> I also want to add that Bitbucket Server 5.x includes totally
> rewritten GC handling. 5.
I'm one of the Bitbucket Server developers. My apologies; I just
noticed this thread or I would have jumped in sooner!
On Thu, Jul 6, 2017 at 6:31 AM, Andreas Krey wrote:
> On Wed, 05 Jul 2017 04:20:27 +, Jeff King wrote:
>> On Tue, Jul 04, 2017 at 09:57:58AM +0200, Andreas Krey wrote:
> ...
On Wed, 05 Jul 2017 04:20:27 +, Jeff King wrote:
> On Tue, Jul 04, 2017 at 09:57:58AM +0200, Andreas Krey wrote:
...
> I seem to recall that using --stale-fix is also extremely expensive,
> too. What do the command line arguments for the slow commands look like?
The problem isn't that the expi
On Tue, 04 Jul 2017 11:43:33 +, Ævar Arnfjörð Bjarmason wrote:
...
> You can set gc.auto=0 in the repo to disable auto-gc, and play with
> e.g. the reflog expire values, see the git-gc manpage.
>
> But then you need to run your own gc, which is not a bad idea anyway
> with a dedicated git serv
On Tue, Jul 04, 2017 at 09:57:58AM +0200, Andreas Krey wrote:
> Questions:
>
> What can be done about this? Cronjob 'git reflog expire' at midnight,
> so the heuristic don't trigger during the day? (The relnotes don't
> mention anything after 2.4.0, so I suppose a git upgrade won't help.)
>
> Wh
On Tue, Jul 04 2017, Andreas Krey jotted:
> Hi everyone,
>
> how is 'git reflog expire' triggered? We're occasionally seeing a lot
> of the running in parallel on a single of our repos (atlassian bitbucket),
> and this usually means that the machine is not very responsive for
> twenty minutes, th
Hi everyone,
how is 'git reflog expire' triggered? We're occasionally seeing a lot
of the running in parallel on a single of our repos (atlassian bitbucket),
and this usually means that the machine is not very responsive for
twenty minutes, the repo being as big as it is.
The server is still on g
11 matches
Mail list logo
