We have a project where the main developer mostly develops locally on his own machine (less latency, etc). But the rest of us want to use Glitch. We have the source code in GitHub.

This is a little fraught because Glitch’s “import from GitHub” feature doesn’t merge changes but overwrites anything in Glitch.

The best workaround we’ve thought of is that, to get everyone’s latest changes merged into Glitch, you first export from Glitch to GitHub, merge the auto-generated pull request, and then import from GitHub. And you have to do those in quick succession because any changes made on Glitch while that’s happening will be overwritten.

Does that sound right? Is there a better protocol? Anything clever we can do in the Glitch console to merge instead of overwrite when getting the latest from GitHub?

It’s been a while since I’ve done it, we may of fixed that part. It sounds like your existing workflow of having to import from Glitch is the right/only one for now. (unless of course someone else has a better console suggestion)

Just bumping this thread because this is still a real pain point for collaboration. I keep having to tell people something like

Don’t ever do “import from GitHub” in Glitch because that overwrites what’s in Glitch. The other direction – “export to GitHub” – is fine. It creates a pull request that can be merged in on GitHub.

And I know eventually we’re going to screw this up and lose work or make a mess.

I did learn how to merge in the other direction (thanks @Gareth!) from the Glitch console. It would be pretty amazing if that was the default, built-in way to get code from GitHub to Glitch.

In the meantime, maybe there could be more of a warning on the “Import from GitHub” option to help guard against losing work? Maybe it could even be smart enough to know when there are changes in Glitch that would be overwritten by that and not let you do it?

Extreme proposal: What if you had to go to the trouble of deleting all the files on Glitch to prove that you really wanted to start fresh from the GitHub version? Annoying in many cases but the alternative I argue is worse: lots of FUD around using both Glitch and GitHub to collaborate. Ie, just having to give the warning above makes it feel to new collaborators like “here be dragons”.

PS: To clarify, I’m complaining so hard because of how completely amazing it is to have Glitch as a medium of collaboration and I want to use it for everything but that’s currently a bit fraught when the primary repository of the source code is GitHub.

Thanks for the feedback, @dreeves. When you overwrite a project by importing from GH, you should still have the old code in your git history inside the container. This makes it fairly easy to revert the changes from the console if you’re comfortable with git. I’m in the middle of bringing much better version control support to Glitch right now. Soon you’ll be able to rewind to an earlier version very easily in the UI. I’m also going to revisit GH import as part of that effort.

If you’re seeing GH import blowing the git history away too, let me know and we can dig into it together - that would be a bug, rather than a missing feature.

I’m not sure how reassuring it is that you can undo a destructive import, because you wouldn’t necessarily notice right away and so new edits would happen and while it may be an untangleable mess it would still be a mess. So I think I’d still prefer my extreme stopgap solution of not letting the destructive import happen in the first place, until the new version control features are done.

Either way, thanks so much for the update on the progress on these new features. Super exciting!

PS! Wait! Possible epiphany! Could the import-from-GitHub feature atomically also do an export? Like as part of the import operation it would first do an export. That would create a pull request in GitHub that you’re free to reject or ignore if you really did just want to overwrite what was in Glitch. If you didn’t mean to overwrite, no problem. Just merge in that pull request on GitHub and import again!