4 ms·

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 p

• kevinslin 4y ago
  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
• darkr 4y ago
  I’d recommend using line wrapping at some reasonable line length (e.g 80-120 chars)
  • Macha 4y ago
    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.
• kretaceous 4y ago
  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.
• robenkleene 4y ago
  `git diff --word-diff` solves this by showing changes inline. Example: https://blog.ipspace.net/2020/04/git-tip-word-diff.html https://blog.ipspace.net/2020/04/git-tip-word-diff.html
  • chaoxu 4y ago
    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/6d9ab6eefc6e8d0034aea779208bd10821d47ff1 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-on-non-english-text https://stackoverflow.com/questions/26135133/git-word-diff-o...
• arinlen 4y ago
  > 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 4y ago
    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 4y ago
      There are some options here on SO: https://stackoverflow.com/questions/43122175/automatically-hard-wrap-lines-at-column-in-vscode https://stackoverflow.com/questions/43122175/automatically-h... Prettier options to extensions like Rewrap, one of those might fit your use case.
    • arinlen 4y ago
      > 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.
• JasonFruit 4y ago
  > 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 4y ago
    I think this is pretty normal. Some people like to put linebreaks after every sentence/clause, which makes diffs much more convenient.