4 ms·

I'm probably missing something here: author says that the split diff doesn't work for him, but doesn't say why. His ideal diff is pretty much the same as a spl

I'm probably missing something here: author says that the split diff doesn't work for him, but doesn't say why. His ideal diff is pretty much the same as a split-diff but with redundant context removed (context is only on the left, not on both left and right). What utility does he get out of removing redundant context on the RHS of the pane?

friendzis 3y ago
LHS shows current code, without any modifications. By showing full context in one view (with code browsing capabilities!) and changes in the other, the author is able to browse the code and see what changes, if any, are applied in a particular context. In my understanding the author wants to flip the diff around: instead of looking at changes themselves, the author wants to look at code and see if there are any associated changes. The article is light on detail, but my guess would be that author wants to look at code and browse to implementation/callsite to check if appropriate changes are there.
- lelanthran 3y ago
  > LHS shows current code, without any modifications. By showing full context in one view (with code browsing capabilities!) and changes in the other, the author is able to browse the code and see what changes, if any, are applied in a particular context. That's the bit I don't understand - how does the "changes in the other" help if displayed only as the unified snippet[1]? To my mind, the magic sauce bit is the full code navigation, and there's no reason that the RHS pane has to be limited to a unified diff when it can simply show the whole file with higlighted lines, the way split diff views do on the RHS. [1] Perhaps (and I'm only guessing here), that the RHS must show the entire unified diff for the entire changeset, and not just the unified diff for the current file. To me, that makes the proposal an upgrade from "either show unified diff, or split-diff, file-by-file".
klauserc 3y ago
The author writes > I need to run tests, use goto definition and other editor navigation features, apply local changes to check if some things could have been written differently, look at the wider context to notice things that should have been changed, and in general notice anything that might be not quite right with the codebase, irrespective of the historical path to the current state of the code. The editors/IDEs I've used usually only offer rudimentary support in diffs (goto defn, but only in the same file; maybe auto-completion, but usually not for newly added items; no refactoring functionality)
- pama 3y ago
  Maybe time to try Emacs? The diff support is great. And magit is native to Emacs.
  - junke 3y ago
    smerge-refine is one keybinding I always use to highlight changes in 3-way diffs between base/mine, base/theirs, mine/theirs. The only problem is knowing what mine and theirs mean sometimes.
    - aulin 3y ago
      Also magit-ediff ('e' in any merge conflict) is great and maybe a little more intuitive than smerge
- CraigJPerry 3y ago
  One area where vscode+gitlens plugin beats IntelliJ, the plugin adds in fully featured editable RHS to diff view
  - atombender 3y ago
    IntelliJ's spli diff view is a full editor with code completion, formatting, symbol lookup, and everything.
    - CraigJPerry 3y ago
      Yeah you're right, I have no idea what i was thinking of, intellij's supported this forever.
- lelanthran 3y ago
  > The editors/IDEs I've used usually only offer rudimentary support in diffs (goto defn, but only in the same file; maybe auto-completion, but usually not for newly added items; no refactoring functionality) Sure, but (to me it seems that) that doesn't necessitate the display change he is advocating for. A diff program that has nice code navigation (and/or other IDE features) would be great, but what does that have to do with whether it is displaying the common split-diff, or his take on the split-diff.
exclipy 3y ago
I'm not the author, but I can empathise with them. The diff highlighting can be surprisingly distracting and it can definitely help readability to turn it off. I certainly do turn it off from time to time in my diff viewer so I can see the code with fresh eyes, but I don't have the option to show the unified diff in a split pane.

friendzis 3y ago

LHS shows current code, without any modifications. By showing full context in one view (with code browsing capabilities!) and changes in the other, the author is able to browse the code and see what changes, if any, are applied in a particular context. In my understanding the author wants to flip the diff around: instead of looking at changes themselves, the author wants to look at code and see if there are any associated changes. The article is light on detail, but my guess would be that author wants to look at code and browse to implementation/callsite to check if appropriate changes are there.

lelanthran 3y ago
> LHS shows current code, without any modifications. By showing full context in one view (with code browsing capabilities!) and changes in the other, the author is able to browse the code and see what changes, if any, are applied in a particular context. That's the bit I don't understand - how does the "changes in the other" help if displayed only as the unified snippet[1]? To my mind, the magic sauce bit is the full code navigation, and there's no reason that the RHS pane has to be limited to a unified diff when it can simply show the whole file with higlighted lines, the way split diff views do on the RHS. [1] Perhaps (and I'm only guessing here), that the RHS must show the entire unified diff for the entire changeset, and not just the unified diff for the current file. To me, that makes the proposal an upgrade from "either show unified diff, or split-diff, file-by-file".

klauserc 3y ago

The author writes > I need to run tests, use goto definition and other editor navigation features, apply local changes to check if some things could have been written differently, look at the wider context to notice things that should have been changed, and in general notice anything that might be not quite right with the codebase, irrespective of the historical path to the current state of the code. The editors/IDEs I've used usually only offer rudimentary support in diffs (goto defn, but only in the same file; maybe auto-completion, but usually not for newly added items; no refactoring functionality)

pama 3y ago
Maybe time to try Emacs? The diff support is great. And magit is native to Emacs.
- junke 3y ago
  smerge-refine is one keybinding I always use to highlight changes in 3-way diffs between base/mine, base/theirs, mine/theirs. The only problem is knowing what mine and theirs mean sometimes.
  - aulin 3y ago
    Also magit-ediff ('e' in any merge conflict) is great and maybe a little more intuitive than smerge
CraigJPerry 3y ago
One area where vscode+gitlens plugin beats IntelliJ, the plugin adds in fully featured editable RHS to diff view
- atombender 3y ago
  IntelliJ's spli diff view is a full editor with code completion, formatting, symbol lookup, and everything.
  - CraigJPerry 3y ago
    Yeah you're right, I have no idea what i was thinking of, intellij's supported this forever.
lelanthran 3y ago
> The editors/IDEs I've used usually only offer rudimentary support in diffs (goto defn, but only in the same file; maybe auto-completion, but usually not for newly added items; no refactoring functionality) Sure, but (to me it seems that) that doesn't necessitate the display change he is advocating for. A diff program that has nice code navigation (and/or other IDE features) would be great, but what does that have to do with whether it is displaying the common split-diff, or his take on the split-diff.

exclipy 3y ago

I'm not the author, but I can empathise with them. The diff highlighting can be surprisingly distracting and it can definitely help readability to turn it off. I certainly do turn it off from time to time in my diff viewer so I can see the code with fresh eyes, but I don't have the option to show the unified diff in a split pane.