Re: Forcing GC to always fail
- Date: Tue, 27 Nov 2018 17:55:38 -0800
- From: Elijah Newren <newren@xxxxxxxxx>
- Subject: Re: Forcing GC to always fail
On Tue, Nov 27, 2018 at 4:16 PM Ævar Arnfjörð Bjarmason
> On Wed, Nov 28 2018, Bryan Turner wrote:
> > On Tue, Nov 27, 2018 at 3:47 PM Ævar Arnfjörð Bjarmason
> > <avarab@xxxxxxxxx> wrote:
> >> On Tue, Nov 27 2018, Bryan Turner wrote:
> >> >
> >> > Is there anything I can set, perhaps some invalid configuration
> >> > option/value, that will make "git gc" (most important) and "git
> >> > reflog" (ideal, but less important) fail when they're run in our
> >> > repositories? Hopefully at that point customers will reach out to us
> >> > for help _before_ they corrupt their repositories.
> >> $ stahp='Bryan.Turner.will.hunt.you.down.if.you.manually.run.gc' && git -c gc.pruneExpire=$stahp gc; git -c gc.reflogExpire=$stahp reflog expire
> >> error: Invalid gc.pruneexpire: 'Bryan.Turner.will.hunt.you.down.if.you.manually.run.gc'
> >> fatal: unable to parse 'gc.pruneexpire' from command-line config
> >> error: 'Bryan.Turner.will.hunt.you.down.if.you.manually.run.gc' for 'gc.reflogexpire' is not a valid timestamp
> >> fatal: unable to parse 'gc.reflogexpire' from command-line config
> > Thanks for that! It looks like that does block both "git gc" and "git
> > reflog expire" without blocking "git pack-refs", "git repack" or "git
> > prune". Fantastic! The fact that it shows the invalid value means it
> > might also be possible to at least provide a useful hint that manual
> > GC is not safe.
> > I appreciate your help, Ævar.
> No problem. I was going to add that you can set
> e.g. pack.windowMemory='some.message' to make this go for git-repack
> too, but it sounds like you don't want that.
> Is there a reason for why BitBucket isn't using 'git-gc'? Some other
> hosting providers use it, and if you don't run it with "expire now" or
> similarly aggressive non-default values on an active repository it won't
> corrupt anything.
...assuming no other repo has this one as an alternate, which I
suspect is the issue at play. (I wrote an alternate-aware gc script
years ago when using Atlassian Stash to try to workaround this issue,
but think I only used it for a couple repos and never got around to
deploying it in prod for continuous use, probably worried I had missed
a corner case. Had meant to, but at some point the powers that be
decided to push us toward a different repository manager tool, and
I've long since forgotten most details.)