Git integration using git-remote-helper

[bicheTortue]

Hello,

This pull contains the first drafts of work to delete files when running olcli psuh.

The git integration mitigates most synchronization issues. Its still in Beta but should be good to go in most situations.

The commits made for version 0.1.8 were messing up the getProjectInfo, it works only with the websockets request, which seem to have been removed in 0.1.8....

It supports cloning using the url ( currently only https://overleaf.com is supported ), pulling and pushing.
When cloning use git clone overleaf::<url>.

I plan to add other features in the future like pushing to a git repo in parallel.

Feel free to contact me by email at valentin@barbaza.org if you have any questions.

The getClient function was moved to the client.ts.

Built with the help of Gemini (free).

[aloth]

Thanks Valentin — this is a much better direction than the real-time daemon idea I closed in #6. git-remote-helper is exactly the right primitive: well-defined extension point, no long-running daemon, no Socket.IO subscription state to babysit, just git push resolving to a series of olcli operations. Mercurial and a bunch of other tools use the same pattern. I want this to land.

Two things before I review properly:

1. getProjectInfo regression you hit was fixed in v0.2.0. The 0.1.7 fetch → node http rewrite (in 266d1f2) broke FormData uploads, and Overleaf separately removed the <meta name="ol-project"> tag, which silently broke getProjectInfo() for every code path that depended on it. v0.2.0 added a Socket.IO joinProjectResponse fallback (see getProjectFromSocket() — the same pattern as getRootFolderIdFromSocket()). Could you rebase your branch against current main and confirm getProjectInfo works again? That should let you drop the websocket-only workaround you mentioned.

2. Scope question. Are you open to shipping this as a separate olcli git-remote subcommand (or even olcli-git-remote as a standalone binary in the same repo, registered as git-remote-overleaf so git clone overleaf::... finds it via PATH)? The git-remote-helper protocol is conceptually distinct from the rest of olcli — different I/O model (stdio command/response loop vs. one-shot CLI calls), different versioning surface — and a separate command keeps the main client's surface bounded. Refactoring getClient into client.ts is fine either way; I'm asking specifically about the wiring point.

Some smaller things I'll flag in a real review pass once we're on the same base:

• HTTPS / overleaf.com only is a fine starting point; we'd want --base-url parity with the rest of olcli before tagging it stable
• Need a story for self-hosted instances with custom session cookie names (config get-cookie-name)
• Test coverage — the existing e2e suite (test/e2e.sh, test/e2e-issue7.sh, test/e2e-ignore.sh) is bash-based and uses real Overleaf; we'd want at least a smoke test for clone/push/pull cycles

Don't take any of that as blockers, just thinking ahead. Happy to discuss the design in this thread, on a draft issue, or via email — whichever works for you. Either way, please keep going. This is a real contribution and exactly the kind of integration olcli should support.

[bicheTortue]

Hello,

1. Glad that getProjectInfo is fixed. I am very bad at this part of the developpement.
2. I am not sure what you mean by that. I feel like the olcli push/pull/sync commands will be replaced by the git commands. The olcli project is still useful for authentification and ArXiv format submissions. Tell me what you think !

• I plan on supporting more than overleaf.com, but the way I see it, it would require some modifications to the way cookies are stored (if I got the architecture right). Using a dictionnary of <url,cookie> could allow cloning from multiple, different instances of overleaf.

• I don't know if you explored this already but I think stream lining the authetification process would be a great way to make olcli more accessible. I was thinking of cli authentification or a web pop-up for Oauth.

• I will work on adding the necessay tests, it will certainly prevent me from overriding features while working on others again ! Tho the e2e testing is not so good at testing edge cases.

I don't know what method of communications are common are usually used. It is my first time contributing to a project.

[bicheTortue]

Hi again,

I added all the features I thought of as of now. They include :

• Local compiling
• safe (in all the situations I tested) push/pull and merging
• Automatic login using a browser pop-up

A feature that I would like to add is simultaneaous upload to a git repo, e.g. github, gitlab, etc.

If you think of any other features don't hesitate.

Concerning the e2e tests. I don't think they are that usefull, most problems occurs with synchronisation problem when editing both locally and on the browser. I can't think of any practical way to automize that.

Best regards,
Valentin BARBAZA.

[bicheTortue]

I merged the last version of olcli into my version, I chose to delete the file deletion logic I had added to the cli.ts because the git integration does it much better as git does the heavy lifting.

The e2e tests don't seem to work on my side, but the only changes done to cli.ts are to update to the new dictionary <baseUrl,cookie> way of saving the cookies. It also contains the olcli watch command, here so automatically recompile the pdf on file change, all handled locally. It can either be done with whatever version of latexmk you have installed of using the same docker image as the one used by overleaf.

I think it is ready for merging, tell me if there is something else you need to flag it as ready !

[aloth]

Thanks for the great idea and the effort here, @bicheTortue! The past releases focused on bug fixes, stability improvements, and adding core features (comments, MCP server, configurable timeout, password login). Now that the CLI is approaching feature completeness, I would consider git remote helper integration as a feature in one of the next releases, definitely before v1.0.0.

I have opened #36 to track this going forward. The concept is sound - a fresh implementation can build on the current OverleafClient and sync infrastructure, which has changed significantly since this PR was opened.

Closing this PR in favor of #36. Thank you for pioneering the idea!