> Yes they do. Since when do documentation writers not need to manage
> revisions to their documentation?
They don't want to create and manage branches. They want to work on
branches others have created. However in Git creating a branch is often
implicit or required in ordinary work-flow, which makes it confusing for
> What are they doing using rebase? You should never use that on a branch
> that has been published for others to see.
This is not the place and time to explain how Git works, but in short, if
you don't want to create an implicit branch when pulling, you have to do a
"git-pull --rebase". Rebasing is an essential activity when maintaining
your local repository, but it can also be confusing to non-technical
> Thats not how the real world works. Even with common-or-garden office
> documents, its common for them to be passed around to different people
> who will make comments and submit annotations, all of which have to be
> collated and reconciled together somehow. A distributed VCS merely
> formalizes the process. The more complex the documentation, the more
> important such formalization becomes.
I am sorry, but that it is nonsense. It is impossible to merge binary files
like .DOC, .PDF, artwork, etc. Those ate precisely the type of documents
that non-developers need. Branches are actively harmful to them.
> Concepts of branches, tagging and merging are common to all modern
> version control systemstheres nothing specific to Git about any of
> them. Whats different about Git is the fact that your entire commit
> history is nothing but a DAG, and branches and tags are just pointers
> into that DAG.
I am not interested in Git advocacy. As I mentioned earlier, I find Git
excellent for development (perhaps the best VCS there is), but too complex
for non-developers (and actually for many developers too). The latter is an
observable fact, not just an opinion. The reluctance to accept it is a bit
perplexing to me.