15

I use a version control system (formerly subversion, now git) to write papers, which for me works very well and is convenient. A few times, I even worked with branches for different logical versions of a paper, such as versions submitted to different journals. However, I found branching of little use for paper writing. When I used different branches for different journal submissions, I found myself working only on the "latest" branch anyway, since I can anyway only submit one version per time, and, if it is rejected, will not continue to work on that particular version at a later time. I didn't find any other good use of branching in paper writing, and later skipped it completely.

Is there any advantage of working with several branches when writing a paper with a version control system? How should one organize the writing process in order to profit from such an advantage?

Improve this question

4 Answers 4

Reset to default
16

I use HG, but it is essentially the same as GIT, in that branching is easy. I branch all the time when working with coauthors. The branches tend to be short lived and merged pretty quickly. Basically, I distribute a copy to my coauthors and each set of comments I get back form different branches. This lets me see each authors comments individually. I then work on merging the comments back into the main trunk. Sometimes the merge is easy and the branch is one commit long. Other times it might take longer if I need to work out something (e.g., math, model, or analysis) which might require a couple of revisions before it is ready to go into the main trunk.

Improve this answer
2
  • 7
    A similar strategy: branches are useful when collaborating with co-authors who don't/won't use HG/GIT/etc.. In that case, it is useful to branch of a copy of the paper as it existed at the time when you sent the draft to co-author X; then when you later get comments/diffs/changes, you can apply them and then merge.
    – D.W.
    Nov 20, 2012 at 5:53
  • Several good answers. I accepted this one because it seems to be the most frequently applicable use of branching...
    – silvado
    Nov 20, 2012 at 8:36
10

Personally, I've never used branches (for papers), and would certainly not use branches for different chapters (WTF? like keeping different branches for different files in a programming project; except for the case when different collaborators edit different parts of documents, then - maybe), but maybe it may work for:

Related: git + LaTeX workflow at SO (so, use "advisor" branch):

Branches are also extremely helpful if you are a graduate student. As any grad student will attest, the advisor is bound to have numerous corrections, most of which you don't agree with. Yet, you might be expected to atleast change them for the time being, even if they are reverted later after discussions. So in such cases, you could create a new branch advisor and make changes to their liking, at the same time maintaining your own development branch. You can then merge the two and cherry pick what you need.

;)

Improve this answer
2
  • I like the point for presentation slides. It's not really compatible with my current model of one git repository per talk, but that could be something worth reconsidering. On the other hand, I'm afraid of adding confusion as to where to find my files a few years later...
    – silvado
    Nov 19, 2012 at 15:04
  • 1
    I also tried with an arxiv/non-arxiv version once, but that didn't work for me. I preferred having the two versions available without switching branches, and for porting changes between files direct patching works as well.
    – silvado
    Nov 19, 2012 at 15:08
6

In principle, branches seem like a good idea. A potential use case would be:

  • working on a draft of a paper
  • as we get close to the conference deadline, putting the paper in the conference format and reducing to the prescribed size
  • finding typos in this version and fixing them
  • merging the typos back into the "main version"

In practice, I've never done this, because I'm not organized enough. Also, svn is not as friendly to this workflow as git is, for other reasons.

Improve this answer
2
  • Thanks, this could indeed be useful when starting to prepare a journal version of a paper before having done the final revisions of a conference paper.
    – silvado
    Nov 20, 2012 at 8:34
  • Size reduction is a very good point. That's actually something you might very much want to revert in case the paper is rejected and you plan to submit it somewhere else.
    – tobias_k
    Dec 22, 2017 at 15:53
4

An alternative to branching in some cases, especially for short lived branches like for journal submission, is using patch queues. Mercurial has mq. I believe Git has similar things, but I'm not a git user.

As the question says:

When I used different branches for different journal submissions, I found myself working only on the "latest" branch anyway, since I can anyway only submit one version per time, and, if it is rejected, will not continue to work on that particular version at a later time.

I have had similar experiences when using different (named) branches for submission to different journals. The problem is that one ends up having dead branches which correspond to journals the paper was rejected from, or perhaps journals you never ended up applying to. These live forever in history, which is annoying and sub-optimal.

The advantage of using patches, at least with mq, is that one can maintain multiple patch queues, each of these can be managed as a distinct mercurial repository, and they do not become part of the main repository's history unless you want them to, though of course you can push them to remote since they are regular repositories. Also, one can use them with general non-vcs tools like patch and quilt, which is occasionally useful.

However, when applied, these patch queues are a bona-fide part of a mercurial repository, and can be treated as (anonymous) branches. So, suppose one has two patch queues Q1 and Q2. Then if wants to work with both versions simultaneously, one can make a clone of the main repository, thus resulting in two identical copies of the repository. Then one can apply Q1 and Q2 to the copies, and then work with them as one would with regular branches, using mercurial's merge machinery and so forth.

Another use of patch queues which is very useful, and not specific to paper writing, is to queue up small changes in the queue till one is ready to commit them. I usually just stick everything in one patch, though one could divide the changes into multiple patches. Then, when one is ready to apply some or all of the changes, one can do

hg qref -X .   # apply the patch as local changes, making the patch empty
hg qpop --keep-changes  # pop the patch

This results in

a) the patch being applied as local changes to the working directory

and

b) the mercurial queue patch becoming empty and being removed (popped) from the repository.

Since the patch is now local changes to the working directory, we can easily commit what parts of it we please. When done one can resync the patch with

hg qpush --keep-changes    # push the patch back onto the repository
hg qref                    # put the local changes back into the patch
hg ci --mq                 # commit the changed patch (to the mq repository)

Then the patch is recreated with the portions of the local changes that were not committed.

See the loosely related questions What's the Git approach to publish a patch queue? and git equivalent to hg mq?.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .