Should I suggest to use version control for writing a paper with new collaborators?

Question

I will soon write a new article with new collaborators (my first paper with other people, I'm in math). For some context, I know one of them well, but I've never met the others in person.

I use Git to manage all my papers. I'm wondering if I should suggest the use of Git to them? If so, how much should I press the issue, what should I say when suggesting it?

I can use it alone and apply their changes manually, but it would be infinitely easier if everyone just used a VCS -- and not just for my own personal comfort, because Git (or any VCS) does make writing the paper easier, IMO.

The main issue is Git's learning curve. I can offer to make everything as simple as possible (set up the repository myself, help out with technical issues they might have, direct them to tutorials), but academics are busy people, and they might not want to learn a whole new system for just one paper (even though I believe that were I they, I would then use Git for everything...).

---

I've gotten a lot of answers that don't apply at all to my situations, so to clarify: I'm in (pure) mathematics, where all manuscripts are written in LaTeX. So

1. version control using, e.g., Git, is appropriate, since LaTeX is a plain text format (and not some WYSIWYG thing), and

2. it requires a little bit of technical know-how already, so it's IMO safe to assume that other collaborators are not completely tech-illiterate.

Answer 1

I recently was on the other side of this - I learned git to work with a collaborator on a paper (written in LaTeX). While git is fun, and it's good I learned it, I am not convinced the net time savings were that large, and I found the first steps very frustrating. I would not generally recommend you ask collaborators to learn git - but only ask if they already know it. For papers, maybe things like overleaf/etc might be better?

Giant time losses:

• Trying to figure out how to properly discard changes I made but didn't want to merge, when stash didn't seem to work right...
• Accidentally doing bad commits, etc, and trying to figure out how to move backwards.

This would obviously get easier the more you worked with it, but I found that in the first few months, there was some problem like that, and I ended up deleting everything and re-downloading - this xkcd sounds about right: https://xkcd.com/1597/

Upside:

• Fewer ugly email chains
• Made integrating small edits late in the process a lot easier - I was more willing to make tiny wording changes when it didn't require someone else to integrate it into the final draft, and that I could do it on my time.

Answer 2

Of course you can ask if all are happy with git but as soon as anybody is unfamiliar with it, do not push it. Then go with anything everyone finds OK (may it be svn, Dropbox, or even be sequential processing via Email - I had all of these). In my experience this will make the process much smoother (in other words: Your headache will be smaller this way than it would when there would be somebody on the team who can't work with git - but note that "smaller" may still be huge).

Answer 3

Many people have already answered with good points. Let me add some insights from my collaborations where other co-authors were sometimes (convinced to) using Git, but other times not.

My advice is to explain to your co-authors the benefits of using Git and suggest them to use it, and offer help to setup things to minimize their effort and learning curve. However, don't insist on it if they don't want to.

I've done this once with a paper co-authored with a fellow postdoc, and this worked really well: I first suggested to him some graphical interfaces for using Git, but he actually quickly preferred switching to the command line tools. It was helpful that we were sharing an office, so I could easily help him, he picked up on Git quickly and things went smoothly. Since then he's been using Git for his papers too.

On the other hand, if your collaborators cannot be convinced, Git can still be helpful for yourself by keeping the history of your own modifications, and merging in their contributions via branching. This means that you can (more) easily offer to resolve conflicts due to simultaneous editing of the document. That way, your co-authors may see some benefits of using Git, even though they don't have to deal with it at all. I'm using this setup for some other collaborations, where either we share the paper back and forth by email, or it resides in Dropbox. In this case I make sure that in Git I strip off any version numbering in the paper's filename, to make difference tracking easier.

Finally, various online services such as Overleaf (or others already suggested) allow collaborative editing and at the same time offer a Git (or other VCS) interface. I'm using this setup in another paper I'm writing where one co-author also uses Git and a third does not.

Answer 4

Git only works if your collaborators are actually willing to write plain text instead of WYSIWYG. In the biomedical sciences the use of MS Word is pervasive and people tend to love their tools just as much as we love using Git and $EDITOR.

To answer your question, you first need to know what your starting point is. Do you only have to convice them to use Git or do you also need to convince them to use plain text?

The idea behind plain text is simple, but still, many people find it hard to grasp. So do not underestimate the necessary education effort. Once people appreciate the advantages of plaintext, they might also have an easier time understanding the benefits and usage of Git.

And then there also other solutions like Authorea and Overleaf that other people already mentioned. If your main goal is to avoid sending manuscript drafts via e-mail, this might be a much easier solution that also works for less technical people.

Answer 5

You can try integration of git with Authorea. They are based on git but have a Google Docs interface. Thus, based on your preferred workflow you can achieve a push-pull workflow through git or a real-time collaborative environment à la Google docs.

A new version control system for writing research papers

Answer 6

My experience suggests that few people are interested in using version control in general, and you risk reducing the number of people further by insisting on a harder to use system like Git. Even if you get your collaborators to use Git, the results might not be pretty. I'd recommend something simpler like SVN, which is probably still too complicated for most people. As others have recommended, Google Docs and similar software would be even easier.

More details from a particular case: Several years ago I took a class with several group projects including code and short reports. Using version control made sense, especially given that everyone in my group was a programmer (the class was not nominally related to programming). One member insisted on using Git, with mixed results. Git is powerful, but it's not easy for newbies. I got tired of re-adding lines of code and text because one member of the group didn't know how to properly merge. I doubt this issue would have happened with SVN because the process is much more straightforward.

Answer 7

Git is an efficient tool for collaboration and version control if you work with others who know it. Given the steep learning curve, it may not be efficient at all if your collaborators don't know Git yet.

In particular if this is a one-off collaboration, you may not be able to recuperate the time that you have to invest in troubleshooting and teaching your collaborators how git works.

Only push someone to use your preferred tool if you are prepared to provide support.

Answer 8

It may be better to approach this differently: you may want to ask them what they plan to use for version control. If they are not sure, you could suggest Git. But my guess is that you will face significant reluctance since the learning curve for Git is steep and your colleagues might not want to learn if they feel that it's not the best use of their time.

Answer 9

I'm not sure what the advantage to using Git for the entire workflow is and it can put a burden on a collaborators who are not as keen to learn it. My group does very heavy interdisciplinary work and generally the workflow is as follows:

1. The manuscript is written collaboratively in Google Docs which has revision history.
2. Citations are managed using citation managers such as Zotero.
3. Included items such as figures are kept in the same directory as the Google Doc.
4. Once everyone is happy with the manuscript, it is typeset in LaTeX to be submitted for peer review.

Since the computing skills in the group range from "comfortable using office productivity tools" to "advanced software engineer" this workflow seems to be the best in terms of overall productivity.

Answer 10

When you have a substantial publications list, you can start to push about something like this. But not at this stage.

You can put the versions in Git yourself, and give your collaborators access, and you can offer to provide guidance in case they are interested in uploading a version themselves.

Answer 11

Unless they are software developers, then don't think that they'll have any clue what a git is and maybe not even what a command line is.
Something like Office 365, Google docs or a wiki would be much simpler. Not as powerful, but much simpler.
Simple and done beats powerful anyday.

Answer 12

I would suggest to use some syncing application like Dropbox, Seafile or Owncloud. Many universities host an own owncloud belonging to the sciebo project.

This provides you with

• sychronization
• History and the possiblity to revert to an older version
• Diff to older versions
• Overview who worked in between and which paragraphs were changed by them

If you want to use version control it would be easier to use a linear system like svn to avoid explaining people how to merge diverged histories, which is really out of scope for writing a paper. If you prefer git you can use git-svn to use the svn with git.

Answer 13

You should tell your collaborators to use SourceTrees, and git will become a piece of cake. No need to learn anything.

It is also good for Mercurial.

Good luck with your paper :)

Answer 14

In my opinion, the learning curve with Git is worth the investment. It allows multiple collaborators and provides versioning. Also, you don't need to learn all of Git to take advantage of its features. Even basic commands and a simple workflow will save time in the long run. Also, Git is cloud-based with a host like GitHub or Bitbucket (just make sure you create a private repo). One consideration is the type of files you are versioning. LaTeX works well, because it's in text format (like source code). So you can easily diff with previous versions, view raw files in GitHub, etc. A Word document doesn't work as well in Git.