Paper Statistics with Git

To understand which sections were most heavily edited, I just want to know how much text was changed in each revision of each section. Now, LaTeX and Git can interact poorly with small edits: if each paragraph is hard-wrapped, paragraph wraps differently any time even a single word is changed, leading to huge and unreadable diffs. I have my own strange indentation style for TeX: I start a new line every sentence, and break and indent this line at every phrase. When Git computes a diff, only a single phrase is changed for small edits, so commits can be reviewed and understood easily. This quirk means allows me to use the number of lines changed as a proxy for the amount of editing. The peculiar indentation style keeps this approximation accurate.

We used the subfiles LaTeX package to manage this paper, so every section lived in its own file. Git can also compute the diff of a file between any two commits. Using this ability, I need to:

1. Compute all commits that changed any of the paper’s files.
2. Compute which files each commit changed.
3. Total the lines added / removed for each of these file / commit pairs.
4. Add up the lines changed per file over all commits.

Luckily, Git has tools to get all of the information I need, and shell utilities can do any aggregation.

The data comes out like so:

The question marks in the “current size” column are for now-deleted files. The current size column is there, because I expect longer sections to have more rewrites.

The top-level paper.tex file, which you’d expect to only contain links to subfiles, actually looks like it has a lot of editing going on. This is actually because I didn’t move things out to subfiles until somewhat late into the paper. To fix that problem, I went through each of the commits editing paper.tex manually, and recorded them in the counts for each section that way.

Some sections were once two parts and became one (like the Example and Overview). Also, some files moved around in ways that Git didn’t track. So the totals above need to be recombined into per-section, not per-file, counts.

This produces:

As expected, the biggest churn was seen in the introduction, abstract, and overview, and also (strangely) the macro file. The least churn was in the consistency model through related work sections, with “Models”, which describes ways to embed some earlier work into our approach, having the least churn.

Overall, the numbers support my impression that we wrote many, many introductions and overviews, while the remainder of the paper sailed through easily. What I didn’t realize was just how stark the difference was. For example, the abstract, introduction, and overview together contain 566 lines, which required 4292 lines of editing to produce (a multiplier of about 7.5×). The rest of the paper is 1386 lines, and required only 4047 lines of editing to produce (a multiplier of 2.9×). Maybe seasoned paper-writers know this, but I’m surprised: we spent less time writing and editing the technical 71% of the paper, then we did editing the non-technical 29%.

Here’s hoping that with practice, I’ll have a better idea of how to write introductions and overviews, and that this contrast will lighten. Until then, I know to budget way more time toward the introductory sections.

Consider running a similar analysis for your papers. Which sections took the most work? The least?

Edit: I went calculated the allocation of lines changed between “Models” and “Applications”, which were a single section at first but later split. I also dug up and added up an abortive total rewrite to the Introduction which was on a branch I had not counted when I first wrote this post.