[chaoxu]

git is line based, so good for code.

But not for most markdown files, at least how I use it. I only start new line (actually, 2 new lines) when I reach a new paragraph, and I think this is normal for most people who ever write something in markdown.

So now I get a huge 2000 character line with a few small edits, and I can hardly see where the changes are.

[robenkleene]

`git diff --word-diff` solves this by showing changes inline. Example: https://blog.ipspace.net/2020/04/git-tip-word-diff.html

[chaoxu]

Oh this feature is great. Solves my problem completely.

I wish github would also implement word-diff option.

Edit: Github actually does some form of word-diff! See example here: https://github.com/chaoxu/chaoxu.github.io/commit/6d9ab6eefc...

I also looked up how word-diff work with Chinese language. Found a useful stackoverflow link with other suggestions.

https://stackoverflow.com/questions/26135133/git-word-diff-o...

[JasonFruit]

> I think this is normal for most people who ever write something in markdown

I recognize that I am not normal and this doesn't contradict your assumption, but I use Emacs' fill command to hard-wrap long lines at ~80 characters when I'm writing Markdown. In fact, it's so habitual for me that it causes me problems when writing Gemtext. I keep meaning to disable filling in gemini-mode.

[gnubison]

I think this is pretty normal. Some people like to put linebreaks after every sentence/clause, which makes diffs much more convenient.

[arinlen]

> But not for most markdown files, at least how I use it. I only start new line when I reach a new paragraph, and I think this is normal for most people who ever write something in markdown.

Markdown treats lines separated with a single line break as a continuous line/the same paragraph, and you need to add two or more newlines for Markdown to interpret it as a new paragraph.

Git works just fine with Markdown.

[chaoxu]

This is true.

But how does someone take advantage of it without changing their current behavior: write an entire paragraph and do 2 line breaks.

Always end a sentence with '.\n'? Manually format lines so no line have more than 80 characters?

[cercatrova]

There are some options here on SO: https://stackoverflow.com/questions/43122175/automatically-h...

Prettier options to extensions like Rewrap, one of those might fit your use case.

[arinlen]

> But how does someone take advantage of it without changing their current behavior: write an entire paragraph and do 2 line breaks.

I don't understand your question. Markdown's syntax already requires 2+ newlines to define a paragraph. There should be no change in a workflow if you're already using Markdown.

The only nuance is that if you want git to track changes in each sentence that forms a paragraph, just add a single line break after the punctuation mark. Markdown still interprets that as the same text block, but git is able to handle changes per line.

[kretaceous]

Hmm, interesting. I've not yet come across a situation where I'd need diffing or going back to a change or looking for one. I just use git for syncing.

Nice heads-up to look out for.

[darkr]

I’d recommend using line wrapping at some reasonable line length (e.g 80-120 chars)

[Macha]

Hard line wrapping is not a panacea in this regard, like when you have a words added/removed from a line and then you get a cascading series of changes for the rest of the paragraph as you rewrap it.

[kevinslin]

i think it depends on your writing style. i tend to do a lot of outlining with bullet points so it works pretty well. for longer paragraphs it can definitely be a pain