Latex Git Tips

1. Using git for text/latex

1.1. How to pull with WIP changes in progress

The basic is either commit or stash, committing WIP is ugly, so stash is preferred:

$ git stash; git pull, git stash pop

Without this you constantly have messages such as:

error: Your local changes to the following files would be overwritten by merge:
	abstract.tex
Please commit your changes or stash them before you merge.
#+end_src sh

However, the problem is that you have to do this all the time, and if no changes are pending, the stash push will not do anything and pop will pop the last stashed change, which may be unrelated. A better solution is to configure git to autostash:

#+begin_src sh git pull –autostash

Or, better, the permanent configuration:

git config pull.rebase true
git config rebase.autoStash true

However, some conflicts may have been generated. Check the log (especially if scripting/using from an IDE, git does not return an error code for this!).

Many details here: https://stackoverflow.com/a/30209750

1.2. How to see changes before merge

git checkout main
git fetch
git diff origin/main
git pull --rebase origin main

https://stackoverflow.com/questions/180272/how-to-preview-git-pull

1.3. Write in a way to minimize conflicts and merge

Don't write whole paragraphs on one line, if there is one comma that is changed in the paragraph by another commit that could trigger a conflict. Diff will be unnecessarily large. Unfortunately (?), diff isn't smart enough to identify character-level changes in a meaningful way, it will mark a conflict for any change on the line. If the line is a whole paragraph that breaks all the time (more frequently as the deadline approaches and many people rush to improve the text!).

1.3.1. One sentence per line

  • This creates conflicts only when there are multiple changes to the same sentence. There needs to be manual handling to make sure the merge of both changes isn't conflicting, this is good when hitting the same sentence.
  • Depending on the editor, it's ugly (see below for emacs).

1.3.2. If not one sentence per line, refill text carefully

Refill text to 80 columns (e.g., M-x fill-region), only when significant changes were done. Don't do it when only small changes are made, this creates a large unnecessary diff, which leads to unnecessary conflicts and makes the diff harder to understand. Better to break the "80-columns rule" than get conflicts.

1.4. If using emacs

  • deactivate auto-fill-mode
  • make your local configuration to `.dir-locals.el` and add it to .gitignore (could be your local git ignore)
  • if a `.dir-locals.el` is committed with global settings, make sure it works for others. In case of need add your own settings to `.dir-locals-2.el`
  • use magit
  • if other users are using overleaf, it is possible to use git connector to overleaf. There is a plugin to sync with overleaf (kind of works, for example, usage with straight/use-package):
(use-package emacs-overleaf
  :straight
  (emacs-overleaf :host github
	    :repo "Jonghyun-Yun/emacs-overleaf"
	    :branch "master")
    :commands (overleaf-setup)
  )

1.5. Emacs config

Add to .dir-locals.el:

((latex-mode . ((eval . (auto-fill-mode 0))
		(eval . (visual-fill-column-mode 1))
		(TeX-master . "main")
		)
	     )
)

This deactivates auto-fill, activates visual-fill-column-mode and sets the main file (for overview C-= , etc). Adapt to the file name.

1.6. Put all the text in one file, unless it's a very large doc like a thesis.

Seriously, it's a pain to split a paper into 10 files or so, impossible to easily make global changes, etc. With the above things, it's easy to avoid conflicts, and even if there are conflicts it's not such a big deal.

1.7. Write with Grammarly or other grammar checker

Grammarly helps with writing if Grammarly isn't supported by your editor, you can always make a pass online (like with Github/Gitlab online editor or Overleaf and the Grammarly browser plugin). At EURECOM there is a Grammarly account, search details at https://moodle.eurecom.fr

1.7.1. Prefered option: languagetool

Languagetool is free and open source and works great (many integrations: editors, browsers, etc.). It is possible to install a local server, this avoids sending all your text to an online service and works also without network.

2. General paper writing tips

2.1. Read this book:

Justin Zobel , (2014) , "Writing for Computer Science"

and refer to it in case of doubt about writing.

2.2. Capitals

Only proper names are capitalized, and even these can be in lowercase if the name is in common use; for example, the capitals in the phrase “the Extensible Hashing method” should be in lowercase. […] In technical writing it is usual to capitalize names such as “Theorem 3.1”, “Figure 4”, and “Section 11”.

– Zobel et al p128

More importantly, be consistent.

2.2.1. Capitals in acronyms

The International Monetary Fund is the proper name of an organization, so if you spell out the abbreviation IMF, you capitalize.

On the other hand, scuba stands for self-contained underwater breathing apparatus. That's not a brand name or anything, so it's not a proper noun and not capitalized.

Or, if it concerns you that scuba is also lowercase, try CSMA, which stands for carrier-sense multiple access.

https://english.stackexchange.com/questions/491575/acronyms-and-initialisms-uppercase-lowercase-or-either

2.3. Citations

When using "\cite" always glue it to the previous word with a non-breaking space

  blah~\cite{XXX}

2.3.1. Non-breaking spaces

Don't add a breaking space (normal space) before the non-breaking space, like that:

  blah ~\cite{XXX}

This makes the non-breaking space useless :)

2.3.2. If you don't cite author names don't say by [XX]

"A large-scale analysis by~\cite{bacis2024assessing} assessed"

but instead "A large-scale analysis~\cite{bacis2024assessing} assessed"

2.4. Short sentences

Don't make too long sentences. One idea one sentence. Split long sentences and use connection words.

2.5. E.g., i.e., etc…

2.5.1. E.g., i.e., are always having one comma before and after

No comma before if it is the start of the sentence. The coma is for "breathing while reading aloud", there is always a comma after "for example", "that is to say,".

2.5.2. Never use "i.e.", and "etc." in the same list

Words like "i.e.," "for example," and other similar ones are all indicating that the list is incomplete, so adding "etc" is redundant.

2.5.3. don't confuse "i.e." "e.g." and "aka"

AKA stands for "as known as"

"i.e.," stands for "this means,"

"e.g.," stands for "for example,"

2.6. Many more TODO/Don't Do in this guideline:

2.6.1. Always put a dot at the end of a caption

There is no clear rule about this, but it's the most common and looks better. Either way be consistent.

2.6.2. Latex traps spaces missing when commending end of line

This

bla bla,%commented thing
tuut

Latex generates "bla bla,tuut" with a missing space before "tuut".

This is because there is a comment right after the last character of the line. Just adding a space like:

bla bla, %commented thing
tuut

This gets a space inserted in the PDF. Strange stuff !

3. Other small/various latex tips

3.1. Fonts (to look like Word, in case of a template to follow)

`wordfeel` and `times new roman` see ~/scripts/templates/wordfeel

3.2. Diff with difftastic

ediff works quite well in emacs, but difftastic shows even better the differences. Call with:

GIT_EXTERNAL_DIFF=difft git diff

$ GIT_EXTERNAL_DIFF=difft git show HEAD –ext-diff

View changes from recent commits on the current branch with difftastic:

$ GIT_EXTERNAL_DIFF=difft git log -p --ext-diff

More here: https://difftastic.wilfred.me.uk/git.html

and for emacs/magit integration : https://tsdh.org/posts/2022-08-01-difftastic-diffing-with-magit.HTML

Author: Aurelien Francillon

Created: 2025-07-13 dim. 11:07

Validate