I think the most important difference is conflict resolution. If you modify a file on DropBox and save it while someone else still has it opened, you're going to end up with two files, one named youFileName (conflicted copy of someone 06/20/13).tex and the original. Not only does Git allow you to see and fix the conflicts when you merge, it does it automatically most of the time, which is a huge advantage.

I haven't found git to work much differently in practice, at least with papers (I haven't written a book in it). You will end up with way too many conflicts unless you basically "lock" sections through either a software mechanism or agreement, because edits often touch or reorder many paragraphs. A copyediting/wording pass will typically touch every paragraph, for example, and these are more frequent in writing than refactoring or variable-renaming passes are in coding.

You can somewhat improve the situation if you adopt a somewhat weird source-formatting policy, where you write each sentence on one separate long-ish line, rather than flowing by paragraph. Then you will be able to automatically merge as long as nobody has made an edit or move that touches the same sentence, giving you better merge granularity. But even then conflicts happen pretty often, and few people like this style of formatting (maybe it'd work better with tool support).

For a book this might work better, though, because I assume you'd be making less frequent edits, and people would less often be working at the same time.

Note that in principle it's probably better to change your diff software to recognize sentences than to change how you write your latex.

Sure, but in practice, starting each sentence on a new line isn't difficult and works great with standard 'diff'. I actually quite like it for proofreading, since fragments and run-on sentences jump out at you.

> You will end up with way too many conflicts unless you basically "lock" sections through either a software mechanism or agreement, because edits often touch or reorder many paragraphs. A copyediting/wording pass will typically touch every paragraph, for example, and these are more frequent in writing than refactoring or variable-renaming passes are in coding.

As stated above, Dropbox doesn't even try to merge files, but Git does, which is definitely an advantage (at the very least, it tells you where the conflicts are, which is far more reliable than trying to work out the conflicts by hand, or with a separate diffing tool).

Review: If you get into the habit of git diff --cached before every commit, it's a good way to review new changes before they go in, and you don't have to re-read the whole section -- you can just read your changes.

Merges: Git does all the bookkeeping for collaboration -- if you have two people making changes, it's much easier to merge them with VCS. Or an independent contributor can use rebase to, as the manual page succinctly puts it, "forward-port local commits to the updated upstream head."

Discussion: If you use a Web-based product like Github or Gitlab (an open-source, self-hostable GitHub clone), you get an issue tracker and a dedicated discussion thread for individual changes.

Even when there is only single user branching can be quite useful, too. When I was writing my thesis, I usually worked on different parts at the same time. Having each changeset in a separate branch made it easier, especially when I procrastinated by fiddling with various settings like margins, colors and page styles.

> what is the advantage of Git over something like Dropbox

Merging. People can work on the manuscript at the same time, and as long as they edited non-overlapping regions, git will merge both contributions silently and painlessly.

Editing a word processor document stored in a shared Dropbox folder, I guess you'd need to inspect both new versions and do the merge manually?

I'll try: Git repo can be forked, cloned and you can get to keep a local copy of whatever branches you prefer. Managing different versions from different authors while having an "offical" repo with dropbox seems harder to manage with dropbox than with git to me.

edit: just saw your edit :)

I use version control even for personal projects with no collaborators. Just being able to see what's changed since you last recorded is a big win.

> Just being able to see what's changed since you last recorded is a big win.

Particularly with the fuzzy temporal revs thing, e.g. HEAD@{1 week ago}

Merging? If you have 2 dozen authors collaborating, there's bound to be people working on the same files.