Git merge conflicts when dealing with narrative text

[kirmaha]

I am gradually implementing a writing workflow based on Markdown and Pandoc. I started using Git to ensure versioning and traceability of my work. However, I've encountered a significant challenge with merge conflicts when working with narrative text, which I suspect you encountered too: Git highlights differences at the line level, which is not ideal for text where small changes, such as punctuation adjustments or spelling corrections. I'm searching for a way to get a better granularity, closer to what is found in the change tracking features of word processors like LibreOffice Writer or MS Word.

I've explored conflict management tools like Meld and KDiff3, which can highlight changes within lines, but both have limitations that make them "not ready" for narrative text (explained respectively here and here).

Given your experience with academic writing, I wonder if you found any effective strategies or tools to manage merge conflicts in Git when dealing with fine modifications in narrative text? Your insights would be greatly appreciated!

[katrinleinweber]

Thanks for sharing your observations, @kirmaha & greeting to 🇧🇪 :-)

I'm not sure anymore, how often I had merge conflicts… 🤔 Certainly, there were some, but I didn't juggle different contributors. So all conflicts must have been triggred by me, probably due to parallelising too many tasks. 🦶🔫

As for merge tools, I bought Kaleidoscope early on. To some extend, it can auto-resolve conflicts. Never having tried another properly, I can't compare it, though.

Also, to avoid conflicts in the first place, I'd suggest to:

1. break sentences up into multiple lines, see this longer discussion about various approaches.
2. fix as many little things as possible quickly (before or after content commits). Uusing any spellchecker, LanguageTool (helper one & two), Vale, or similar should help, but overdoing it can distract from the actual writing and your own tone/style/voice.
3. Not worrying about clean Git history. Some cleanup is possible without conflicts, but even that seems hardly worth the time. Good commit messages on the other hand are a good skill to have!
4. Good old paper task list, to force as many tasks as possible into a linear sequence.

[kirmaha]

A huge thank you, @katrinleinweber, for taking the time to respond in such a helpful way.

I have indeed considered breaking sentences up into multiple lines, and I was initially reluctant, but that paper certainly provides valuable insights on the matter. Your point about parallelizing too many tasks resonates as well; while I still need to manage reviews from colleagues, it might be possible to reduce the frequency of merge conflicts, though I don't think I can completely avoid them.

Anyway, your answer provided me with the insights I needed to move forward with my project. So thanks again, have a nice day, and greetings to... well, 🇪🇺!