| Fork => Modify => Merge. Suppose you have a 100 page gdoc. You start editing one paragraph per page, and voila, everything is fine. Casual edits are consistent "in context". However, if you start editing on page 1, then skip to page 100 and go back to page 50, then it's possible that while "there was no conflict" (people weren't editing the same section of the doc at the same time), however, the document was in a "semantically inconsistent state" while you were making your edits (ie: someone trying to "compile" your doc in between the beginning and conclusion of your changes would have had a logic error until you'd made that final edit). Git (and branching, as you're suggesting) allows you to select the next "actual" future from many "plausible" futures. Think of A.C.I.D. You want your changes to be atomic (gdoc edits are not atomic across multiple "pages"), you want your changes to be durable (gdocs may/may not hit your definition for durability if changes can be made to the lines arbitrarily), consistency and isolation are also compromised with the free-flowing editing style you're describing. Imagine dumping a python script into gdocs, pulling down the contents, and running it through a local python interpreter. You could get pretty far with low amounts of edits and using the "comment" feature liberally, but once you try and "propose a refactor" you immediately need to "fork the universe" and have two (or more) semantically distinct representations of the document, or some way of queuing "multi-page edits" such that each could come in ... some sort of "merge queue" .... ;-) |