Is this correct for git into github?

I deleted the .git folder cause it was for some reason commiting everytime i did anything. Is there some way to turn this off so I don’t end up with 100 commits in 10 minutes:

$ git status
On branch master
Changes not staged for commit:
(use “git add …” to update what will be committed)
(use “git checkout – …” to discard changes in working directory)

    modified:   .gnupg/random_seed

no changes added to commit (use “git add” and/or “git commit -a”)

app@ookmakyi:~ 23:51
$ git log
commit 74d44d348847807a324cd97374884dcd70d2c8a6
Author: ookma-kyi <>
Date: Mon Sep 27 23:51:29 2021 +0000

🐬🍃 Checkpoint

commit 8eb6bfa814124bbdffd91c302883899d9b8aec81
Author: ookma-kyi <>
Date: Mon Sep 27 23:39:29 2021 +0000

🌨🎌 Checkpoint

commit 8b0b33b404ef2451f7e46b5b0232af5102f5335f
Author: ookma-kyi <>

This seems counterproductive when I push it to my github repository.

I don’t know what you might have set (or what may have happened) to make it push to git without you expressly telling it to. Do you have some sort of script running re: git?

I have all my projects in git and though I mostly just pull from them these days have once in awhile pushed changes.

Hi @Ookma-Kyi

Glitch commits to its internal repo every few minutes when you’re changing files, and this powers the Rewind functionality.

You can turn off ‘Checkpoint’ commits using the advice in this project: https://glitch.com/edit/#!/stop-default-commits?path=README.md%3A1%3A0

Hope it helps!

SteGriff… do you have a second? How does that setting get set to begin with? Part of a template because I don’t recall seeing it.

Hey, the short answer is I don’t know.

But fundamentally, the Glitch environment is a custom Linux image in a container. So the team can add whatever script-fu they want in there to control how it handles git etc. Plus there’s the whole Glitch backend. So there are multiple tiers where they could have implemented the automatic “Checkpoint” commit functionality.

The override in git hooks is just a hook; it doesn’t have anything to do with the origin of the Commit event, it just sees that a commit is happening (from any source) and nullifies it if it sees the word “Checkpoint” :slight_smile:

Just my understanding! :sweat_smile:

Thanks. That’s a little disconcerting. Not a show stopper by any stretch but it seems to me that these types of things could be options making them both obvious and controllable through an interface.

That there is a documented script makes that even more obvious.

I see where you’re coming from. But I think the big difference in usage is that whereas you’re not keen on the Glitch editor, others (like me) work exclusively in it. And, as I understand it, Glitch-the-company view the editor as a unique selling point.

Glitch ain’t heroku at the end of the day; it’s not an entirely unopinionated code-running system, but a somewhat opinionated app creation environment with sensible defaults that are designed to make coding more fun and less arcane.

One article that comes to mind is Joel Spolsky’s intro/reveal of Glitch (then Hyperdev): https://www.joelonsoftware.com/2016/05/31/introducing-hyperdev/

But I agree that “these types of things could be options”… as long as they were ON by default :wink:

1 Like

I still play ZDoom every day there are multiple dozens of options most of which nobody changes but if the software needs a value and there is a range of acceptable values there is no reason not to expose those to users in a straightforward manner. In this case they are in a .ini file tied to the user account.

One of the reasons people may not be so keen on the editor might be due to the relative lack of customization. Note again the original poster who wasn’t impressed with a feature that granted some might find helpful.

Generally speaking I think we can agree that a customizable editor is at least as good a selling point.