We have a project under git revision control with only a single branch. We need to remove every new whitespace-separated word that was introduced for the first ever time in a given file by a specific author.

To clarify, at this point we have the HEAD checked out. Now, in an example file named introduction.tex, if there is a sentence "Enlargement of the user-base is beneficial ...", I'd like a bash script with suitable git commands that:

  1. Parses the current whitespace-separated word (in the example, for the first iteration, this will be Enlargement). Maybe by using a regex like \b[A-za-z+]\b for word detection.
  2. Check if the word is minimum 5 characters in length. If not, keep moving to next word until this condition is satisfied. If satisfied, move to #3 below.
  3. Check entire history of the project to find out who originally made the commit that introduced this word.
  4. If author of that specific commit matches johndoe, then remove the word under consideration from the file.
  5. Repeat #1 -- #4 until all words from the file have been parsed and the original words by the specific author pruned off.

Treatment of High-Frequency Occurence Words:

It is important to ignore common keywords like a, an, the, of, for, if, then, but, else, not, any, or, nor. So, I propose to keep the minimum length to 5 characters in the string for the word to qualify for removal

Basically the idea is to eliminate or revert English-like contributions made by a particular author. How can this be done?

Post-Processing by latexdiff:

This question is for producing a diff report after removing contributions by the author. After pruning the text (ie. after I get the answer to this question),I intend to use a standard, yet amazing perl script latexdiff that can detect these word removals (or indeed any other difference among the two latex files) and output a composite PDF, highlighting the removed words with red striketrhoughs. All that I need to do is identify and remove the words originally introduced by the other author (i.e. my core question here). Therefore all sentences in the composite pdf shall remain coherent with no loss of meaning, but will continue to retain the removed words still in the same location but additionally simply have red strikethrough marks over them.

Background and Context:

This is in an academic context. The git project is a LaTeX repo of a manuscript. I am in an authorship dispute with a co-author of a paper which therefore did not get submitted to any journal. We are both PhD students. To claim each our copyright of the words for use in our respective theses, our PhD advisor has asked to submit our respective claims on the words introduced in the manuscript by each of us, for reuse in our theses and steer clear of plagiarism accusations. We both had committed to the same repo and now I am thinking of leveraging the power of git and shell along with git-grep, sed, awk, perl or whatever to help me claim the correct words I contributed with integrity. Your help will be much appreciated.

Starting Point:

git log -S --oneline 'enlargement' -- introduction.tex correctly shows the list of commits that touch that case-sensitive word, i.e. enlargement in this case. The oldest commit in the list shall help to identify the committing author. We are simply looking for the "big,technical words" that explains a concept first. I am already doing this manually with that starter git command. But I need to automate this because there are around 10 such files. I obviously don't want to manually do this for every 5+ character word in every file.

  • I imagine since you’re trying to go to all this trouble, that reverting the author’s commits wouldn’t be appropriate instead? Jul 18, 2018 at 11:47
  • @StephenKitt I have now updated the question to explain the context. Jul 18, 2018 at 11:56
  • 1
    Your step 3, as is, is flawed and I really think you need to imagine doing things otherwise. Why? Because after having extracted the words, while you can use git log -S you loose the fact of where in the file this word was. You can have multiple times the same word... I would instead work on each commit one by one and using git blame. Tracking a word, in history, without context will create more problems than solutions. Also I doubt that your whole problem could be fully automated. Jul 19, 2018 at 1:17
  • Rather than deletion, it would make a lot more sense to somehow identify all words in the HEAD revision which come from that author and produce a version of that file in which they are flagged somehow like [[word]]. Then you'd have to manually go through the file and adjust the wording to eliminate those words. To preserve the grammar and meaning, you can't just delete those words; you have to replace them with synonyms, or else restructure the containing sentences entirely.
    – Kaz
    Aug 17, 2021 at 20:30


You must log in to answer this question.