Thomas, I'm unclear as to what feature/configuration option you're proposing as a potential substitute for being able to set/unset line wrapping in the changes display. It's a feature I'm desperate to see added to SmartGit as well, and if there's currently an analogue for it in the software that I'm unaware of I'd like to shed that ignorance posthaste. Could you more precisely describe what you're suggesting we try?
This is essential nowadays. Most (all?) tools we use support auto-wrap, and this is very important for things like docblocks or documentation files. Force users to wrap every 80 or 120 chars is not good because a small change in the middle of a paragraph may force all the following lines to incorporate changes that are not really meaningful.
Are you not implementing this because you don't think it's needed? :| It's needed. I have to switch to WinMerge for diff view of README files for example, because SmartGit doesn't wrap lines.
It's really weird to have to visually prove that "other editors have line wrapping", as if that was a novelty in 2020, but here it goes, Meld, a common diff viewer for Gnome...
Hi, is there a roadmap for this feature? I have to open another tool to view these long lines from a git log diff, which defeats the purpose of choosing Smartgit as the ultimate git tool.
I think I was a bit enthusiastic about how nice this tool is but this simple usage is still not touched in the last 6 years.
I regularly work in a legacy code base where the line length is well past the 400 character mark (don't ask), and multiple changes to such long lines tend to get overlooked unless I force myself to scrub the horizontal scroll bar on these long lines to see if there is more than the one highlighted change.
And related: SmartGit tries to horizontally scroll the first diff for a line into view, but I regularly find it fails to do so for these long lines when they occur near the bottom of the file (or if there are more than a certain amount of them in a file?). In that case the line itself is nicely vertically centered into view, but the exact word diff is not visible since the horizontal scroll bar is stuck at position 0, again forcing me to scroll the change window to hunt it down.
As for inspiration from other merge tools: WinMerge can also enable line wrapping in all windows for as long as I can remember. Needless to say that I have set WinMerge as my external diff & merge tool, but there is no replacement for the in-built diff viewer in the SmartGit "Changes" pane.
Also +1 for this feature. Reading changes/diffs for files with long lines is very difficult (as a good example - in LaTeX I write one sentence per line, which keeps the changes neat, but then they're hard to read in SmartGit).
The fact that this basic feature is (still) missing alone stops me for purchasing a commercial license of otherwise great product for many years already (each time when I think of purchasing, I check that this feature is missing and say "no way that I will pay for this" to myself). For me, it's like if the SmartGit UI were in Japanese and the authors would refuse to translate it to English. Word wrapping is a must nowadays in the era of large HiDPI monitors and modern code editors like VSCode and Qt Creator that easily allow to forget about hard word wrapping in the source files because they do excellent job at dynamic (soft) word wrapping that nicely adapts to the editor width and font size. Hard word wrapping was understandable in the old days of text mode monitors that could only display 80 characters in a row but these days have long gone. Any other modern diff tool (including VSCode and Qt Creator built-in diff viewers) supports word wrapping without any problems (so no excuses are accepted here). I have to use them instead of SmartGit because it is nearly impossible to inspect diffs and merge modern code that has no hard line length limit with SmartGit and I miss a bunch of its really powerful features. Please implement word wrapping and I will buy a license right away.
In the era of AI, this is more important than ever because LLMs tend to speak markdown and write markdown files with entire paragraphs on one line. Diffing markdown has become an important workflow for developers.
Also, Kaleidoscope diff tool, and most other diff tools, have this ability.
Following up on my comment from a few months ago. Rather than add another +1, I wanted to find out how big this change actually is.
I spent 15 minutes with an AI agent, and it works. Screenshot attached — SmartGit 26.1.049 with a "Wrap Lines" option added to the Changes-panel view menu: soft-wrapped lines, no horizontal scrollbar, line numbers on the first visual row with continuation rows unnumbered, inner-line diff highlighting still tracking across wrapped rows, and both sides staying aligned.
The reason it isn't a big change is that the Changes panes are SWT StyledText. setWordWrap(true) does the layout — no custom wrapping renderer needed — and the line-number gutter already paints per logical line from getLinePixel(), which is wrap-aware, so the numbering behaviour people have been asking for in this thread falls out for free.
Three places assume exactly one screen row per logical line:
setFixedLineMetrics(), called from the diff widget's setFont(), pins a uniform row height. With wrap on, SWT still draws the wrapped text but reserves no vertical space for it, so continuation rows paint over the following lines. This is the non-obvious one: the widget reports getWordWrap() == true while getLinePixel(i) still returns a clean i * lineHeight.
The scroll-sync adapter maps line index to y as index * lineHeight and derives total height from lineCount. Both break once line heights vary, and the two sides drift apart. getLinePixel() / getLineHeight(getOffsetAtLine(i)) fix it.
An overlay painter passes a line index to StyledText.getLineHeight(int), which expects a character offset — invisible while every row is the same height, wrong once they aren't.
To be clear about scope: this is a spike, not a finished feature. I didn't touch the overview ruler, collapsed-hunk geometry, find / "Go to Line" / caret movement across visual rows, or the separate Compare and Conflict Solver editors. And I'm not going to guess what it costs to productionize — I can't see your source or your QA bar.
Two data points from this thread that matter more than my prototype: one commenter says this single missing feature is why he has never bought a commercial license, and GitKraken shipped line wrapping in v11.9.0 in February. I'm a paying, enthusiastic daily SmartGit user, and this is the last thing that still sends me to another tool for diffs.
It was more complicated than just invoking `setWordWrap(true)` as you can see in your screenshot. I think, the first 26.2 preview will contain the word-wrap feature for the Changes view.
Robert, please give the latest 8.1 preview a try. It's not what you are asking, but maybe helps a step forward.
Thomas, I'm unclear as to what feature/configuration option you're proposing as a potential substitute for being able to set/unset line wrapping in the changes display. It's a feature I'm desperate to see added to SmartGit as well, and if there's currently an analogue for it in the software that I'm unaware of I'd like to shed that ignorance posthaste. Could you more precisely describe what you're suggesting we try?
This is essential nowadays. Most (all?) tools we use support auto-wrap, and this is very important for things like docblocks or documentation files. Force users to wrap every 80 or 120 chars is not good because a small change in the middle of a paragraph may force all the following lines to incorporate changes that are not really meaningful.
Could you please show a screenshot of most/all tools that support line-wrap for a file compare? Thanks in advance.
Hello,
Here's an example in PHPStorm :
As a matter of fact, GitKraken also didn't have it... until v11.9.0 released on Feb 3, 2026!
So it's not too late to catch up with the competitors, I guess?
Are you not implementing this because you don't think it's needed? :| It's needed. I have to switch to WinMerge for diff view of README files for example, because SmartGit doesn't wrap lines.
It's really weird to have to visually prove that "other editors have line wrapping", as if that was a novelty in 2020, but here it goes, Meld, a common diff viewer for Gnome...
Hi, is there a roadmap for this feature?
I have to open another tool to view these long lines from a git log diff, which defeats the purpose of choosing Smartgit as the ultimate git tool.
I think I was a bit enthusiastic about how nice this tool is but this simple usage is still not touched in the last 6 years.
+1 for this basic feature.
I regularly work in a legacy code base where the line length is well past the 400 character mark (don't ask), and multiple changes to such long lines tend to get overlooked unless I force myself to scrub the horizontal scroll bar on these long lines to see if there is more than the one highlighted change.
And related: SmartGit tries to horizontally scroll the first diff for a line into view, but I regularly find it fails to do so for these long lines when they occur near the bottom of the file (or if there are more than a certain amount of them in a file?). In that case the line itself is nicely vertically centered into view, but the exact word diff is not visible since the horizontal scroll bar is stuck at position 0, again forcing me to scroll the change window to hunt it down.
As for inspiration from other merge tools: WinMerge can also enable line wrapping in all windows for as long as I can remember. Needless to say that I have set WinMerge as my external diff & merge tool, but there is no replacement for the in-built diff viewer in the SmartGit "Changes" pane.
Also +1 for this feature. Reading changes/diffs for files with long lines is very difficult (as a good example - in LaTeX I write one sentence per line, which keeps the changes neat, but then they're hard to read in SmartGit).
I'm working on a Latex document, so not code, and paragraphs don't have line breaks. The lack of word wrapping is killing me.
The diff view doesn't support line wrapping? It is very difficult to view or resolve changes in file types that have long lines, like ipynb.
Also +1 for this feature. Is there any roadmap to include line wrapping in the diff view?
I miss this feature almost daily. Would be great to get it
The fact that this basic feature is (still) missing alone stops me for purchasing a commercial license of otherwise great product for many years already (each time when I think of purchasing, I check that this feature is missing and say "no way that I will pay for this" to myself). For me, it's like if the SmartGit UI were in Japanese and the authors would refuse to translate it to English. Word wrapping is a must nowadays in the era of large HiDPI monitors and modern code editors like VSCode and Qt Creator that easily allow to forget about hard word wrapping in the source files because they do excellent job at dynamic (soft) word wrapping that nicely adapts to the editor width and font size. Hard word wrapping was understandable in the old days of text mode monitors that could only display 80 characters in a row but these days have long gone. Any other modern diff tool (including VSCode and Qt Creator built-in diff viewers) supports word wrapping without any problems (so no excuses are accepted here). I have to use them instead of SmartGit because it is nearly impossible to inspect diffs and merge modern code that has no hard line length limit with SmartGit and I miss a bunch of its really powerful features. Please implement word wrapping and I will buy a license right away.
In the era of AI, this is more important than ever because LLMs tend to speak markdown and write markdown files with entire paragraphs on one line. Diffing markdown has become an important workflow for developers.
Also, Kaleidoscope diff tool, and most other diff tools, have this ability.
Following up on my comment from a few months ago. Rather than add another +1, I wanted to find out how big this change actually is.
I spent 15 minutes with an AI agent, and it works. Screenshot attached — SmartGit 26.1.049 with a "Wrap Lines" option added to the Changes-panel view menu: soft-wrapped lines, no horizontal scrollbar, line numbers on the first visual row with continuation rows unnumbered, inner-line diff highlighting still tracking across wrapped rows, and both sides staying aligned.
The reason it isn't a big change is that the Changes panes are SWT
StyledText.setWordWrap(true)does the layout — no custom wrapping renderer needed — and the line-number gutter already paints per logical line fromgetLinePixel(), which is wrap-aware, so the numbering behaviour people have been asking for in this thread falls out for free.Three places assume exactly one screen row per logical line:
setFixedLineMetrics(), called from the diff widget'ssetFont(), pins a uniform row height. With wrap on, SWT still draws the wrapped text but reserves no vertical space for it, so continuation rows paint over the following lines. This is the non-obvious one: the widget reportsgetWordWrap() == truewhilegetLinePixel(i)still returns a cleani * lineHeight.index * lineHeightand derives total height fromlineCount. Both break once line heights vary, and the two sides drift apart.getLinePixel()/getLineHeight(getOffsetAtLine(i))fix it.StyledText.getLineHeight(int), which expects a character offset — invisible while every row is the same height, wrong once they aren't.Full write-up, with the specifics: https://gist.github.com/aiba/f735dad34a86820988c59f53afb0de83
To be clear about scope: this is a spike, not a finished feature. I didn't touch the overview ruler, collapsed-hunk geometry, find / "Go to Line" / caret movement across visual rows, or the separate Compare and Conflict Solver editors. And I'm not going to guess what it costs to productionize — I can't see your source or your QA bar.
Two data points from this thread that matter more than my prototype: one commenter says this single missing feature is why he has never bought a commercial license, and GitKraken shipped line wrapping in v11.9.0 in February. I'm a paying, enthusiastic daily SmartGit user, and this is the last thing that still sends me to another tool for diffs.
It was more complicated than just invoking `setWordWrap(true)` as you can see in your screenshot. I think, the first 26.2 preview will contain the word-wrap feature for the Changes view.
That is amazing amazing news, I can't wait for the 26.2 preview!