Hacker News Reader

Comment by madeofpalk | Hacker News Reader

Git does not have colaboration tools. It's very much a "work in a silo for a period of time and then evtually figure out how to mash these things together" approach.

View on HN

That is false. See the built-in git-send-email [0] and git-am [1] commands.

You may not like it, don't use it, etc. But Git does have collaboration tools.

[0]: https://git-scm.com/docs/git-send-email

[1]: https://git-scm.com/docs/git-am

I meant in the sense how it was compared to google docs

Has anyone tried to build real-time collaboration on git? What if every participant would run a system that saved on every keystroke, committed and synced with the remote? It would break due to conflicts as soon as two concurrent edits were too close to each other, but you could probably just accept either commit when they’re so granular and happening in real time. The conflict is going to be obvious and fairly easy to resolve since you will see it happen in the document itself.

EDIT: For some reason, speculating about the potential to repurpose a technology is attracting replies that point out how it wouldn’t work seamlessly with how they are currently using it. I’m not even mentioning editing code, and I’m certainly not proposing that you try this in a random Git repo where other contributors aren’t expecting it.

Keep in mind that a big part of working with a VCS is refining your code until it is done or ready to be merged. Syncing on every keystroke would drown others in noise and I'm usually not interested to see my colleagues' unpolished work-in-progress code.

Every time you modify a file in git you're actually creating a new file. Committing every keystroke would create a massive number of files that only differed by a single character. If you wanted to have a history of changes that can be shared and potentially merged then you would want deltas instead. A better underlying technology would be something like CouchDB https://docs.couchdb.org/en/stable/index.html

I think that's close to what overleaf.com is doing for LaTeX.

That’s interesting. Their website mentions Git integration [1] but I don’t get the impression that their real-time editing is built on Git. Do you have a reference for that?

1: https://www.overleaf.com/learn/how-to/Using_Git_and_GitHub

This problem is what CRDT's are good for. I'm not sure if Git is the right tool to build this on top off.

My comment speculates about what it might be like to repurpose Git for this, so I hope it’s clear that I’m also not sure if it’s the right tool.

CRDTs have the problem the article brings up, that they’re usually very specific to the data they’re modeling and need support from a very purpose-built editor. Git is supported by a lot of tooling and uses plain text which works everywhere.

True but how would you create a useful client without having access to a data format that is specific to the application?

... why would you want that? How would you ever run the program when it's broken on every keystroke?

It may be the case that the Git model is good enough for the way a lot of people want to collaborate, if combined with a nice UI.

Maybe "save" tries to commit, and pulls up a diff interface if there is a conflict? UI indications of other people's commits pending, and maybe merge those with current state of the document if there is no conflict?

There are a lot of edge cases to consider. But I feel like there might be a way to design UX for a Git workflow that makes it comfortable and intuitive to Muggles.

Reply on news.ycombinator.com