Working on Git itself

Here are my notes on trying to submit a patch to Git (referring to the version control system).
Not all of this work is especially supported in Glitch, but I think this kind of stuff isn’t really discouraged either, so I’m posting this anyway.

Getting a copy of the code

Fetching a copy of their repo took too much disk space.
But I worked around that by fetching a shallow copy.


Under the recommended DEVELOPER=1 setting, the current version on the master branch wouldn’t compile, I think due to Glitch having an old version of gcc.
But I worked around that by proceeding without DEVELOPER=1.

Building the default target took too much disk space.
But I worked around that by putting -Os in the CFLAGS and removing the -g.


The in-browser editor freezes for a long time with a checkout in /app.
I didn’t have the patience to see how long it would freeze for.
The Git repo has around 3,600 files, but it still seemed like it was taking a long time, even per file.
This happened on Firefox on Windows.
It was unusable.

This also made it hard to open the console for the project, because you would normally have to get to that from the editor.
But I worked around that by opening the console for another project and changing the project name in the URL.

I did some of the editing in Emacs in the console page.
The latency was very high.
Frequently the session would disconnect and it would kill everything that was running without saving.
Glitch doesn’t have screen or tmux installed.
It was very unpleasant.

Common Emacs keyboard shortcuts would still be handled by the browser, including C-n and C-w.
This might be specific to Firefox.
I lost a lot of work by closing the console tab while trying to move code around lol.
It was very unpleasant.

I worked around some of the issues by moving the checkout to .data and hardlinking some relevant files into /app and using the in-browser editor.

The in-browser editor in Glitch is set to indent with two spaces, which is wrong for the Git codebase.
It’s not configurable either.
But I worked around that by running some code in the browser’s developer tools:

cm = document.querySelector('.CodeMirror').CodeMirror;
cm.setOption('indentWithTabs', true);
delete cm.getOption('extraKeys')['Tab'];

The tab size was still 2 columns though.


Console sessions wouldn’t survive long enough to run the whole test suite.
I went with running one specific test.
I also used Travis CI to run the full test suite on a slower iteration cycle.

Generating the test coverage report took too much disk space.
This might be possible by making a copy in /tmp and running it there, but it would also have to run for a long time.
I went without looking at coverage information.

Sending changes back to the project

The version of Git on Glitch is too old to have git send-email, which is the project recommends.
But incidentally, I had the latest Git built from source, so I kind of worked around that.

That ended up not working though, due to some Perl SSL library being too old on Glitch.
And this I haven’t been able to work around yet.

1 Like

Hey @wh0 thanks for the feedback and your work here, and sorry for the bother! We do have some work ahead of us to improve the various git workflows in Glitch; while I’m not sure anything currently in the plan will address any of these specific concerns I’ll make sure the rest of the team is aware of your experience.

As far as lag is concerned I think the raw file count may indeed be implicated; 3600 files is a lot of files for a Glitch project and I wouldn’t be surprized if our operational transform implementation might have trouble with very large file lists. It’s possible that extended container resources might be able to alleviate some of this as well, although we’re not sure what those might look like or when they might be available.