3 ms·
Git is just the underlying mechanism. What you show to the user depends on your UX/UI. You don't need to show users the words "fork/merge" even. How about: 1.
by rubymamis 3y ago
Git is just the underlying mechanism. What you show to the user depends on your UX/UI. You don't need to show users the words "fork/merge" even. How about:
1. "Edit Joe's text"
2. "Ask Joe for a review"
3. "Do you want to add Alice's changes?"
- jitl 3y agoFor one thing, Git is abysmal at merging rich text formats that need balancing open/close annotation markers, like HTML <strong> and similar. With line/character oriented merge algorithms syntax errors from merge are inevitable. Once you start pulling that thread, like “ok can we clean up such mistakes automatically with a better merge algorithm that understands the content a bit more?” you’ll end up back here at CRDTs. I’ve tried managing markdown docs in git a few times. Even with a team of senior+ engineer git experts it became a pain on frequently changing documents because conflicts were so common — if you wrap markdown at 80 characters, rewording a sentence is more likely to merge conflict than changing a variable in code since it may re-wrap several lines; and if you don’t wrap at all, any change in the paragraph will conflict on the entire paragraph.
- josephg 3y agoYep. And git can't at all handle realtime editing (since you'd need to commit & push after every keystroke). Or handle any non-text data. Even markdown, as you mentioned, can be a pain. CRDTs should be able to solve all of these problems. One thing we're still missing in CRDTs is git style conflicts when merging long running branches. Should be possible - but still nobody has solved that as far as I know.
- mixmastamyk 3y agoRe: markdown in vcs Put each sentence and/or clause on its own line and it will avoid a large fraction of issues. Not all though.