Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unified versus Split Diff

matklad.github.io

Post reply on HN
Print view View original

121–130 of 184 posts

Re: Unified versus Split Diff

#121

Post by gumby »

friendzis wrote: post #2

> For a large change, I don’t want to do a “diff review”, I want to do a proper code review of a codebase at a particular instant in time, paying specific attention to the recently changed areas, obviously every team and ticket is different, but IMO unless the person doing the review is some sort of principal engineer mostly responsible for the code at large, this does not align with I would personally consider a cod…

For most changes I want more context than -c provides, because I see that your change is syntactically correct, but semantically, was your change from Often -c is enough, but not always. I don't believe you can make a hard and fast rule. I think all you can really do is have a diff that allows you to 'jump to definition' or 'list callers', just like you can when looking at the code itself.

Re: Unified versus Split Diff

#122

Post by moritzwarhier »

I admit I don't understand some of the problems mentioned in the article.

E.g. that script that squashes the PR commits together - why would anyone need this, what is wrong with diffing the PR branch and the target branch, using any tool you want?

What forces you to look at the commit history?

I'm perfectly fine with the git CLI and IntellJ for local review work, and Gitlab web UI for the communicative part of a code review.

Only thing I agree with is, I (sometimes) hate the three-way unified diff in IntelliJ for merge/rebase conflicts. Other times (harmless conflicts), I love it over using the CLI.

Personally, I found the example for the desired diff format confusing.

I prefer split to unified diffs though.

Re: Unified versus Split Diff

#123

Post by talent_deprived »

iot_devs wrote: post #50

This is an huge issue for us in a very big and complex codebase with a lot of engineers working on it. Code review is hard because the diff always looks reasonable, the tests always pass and all the basic stuff are always checked. However, it happens often that, even if the changes looks reasonable they are wrong. The whole architecture may drift after one bad change that looks reasonable. As always this is not stric…

A somewhat minor nitpick, the word huge begins with a consonant sound, not a vowel sound. It would be correct to write "a huge issue" not "an huge issue".

Re: Unified versus Split Diff

#124

Post by fanf2 »

grotorea wrote: post #112
ilyt wrote: post #93

Earlier quoted context omitted.

Git doesn't store diffs on logical level. Git operates on snapshots of trees. Commit is not "a collection of changes", it's a snapshot of a tree with attached predecessor of it. Then the another layer (which can be git, but also can be any other tool, adding custom diff tool to git is very easy) uses that to generate diffs. There is zero stopping anyone from adding contextual diffs to Git. Just ask it for content of…

Interesting. Wonder if something like that can be used to make git cleverer about merges for example.

Git’s merge algorithm looks at three versions of the code: the two branch tips being merged, and their common ancestor. It might be better at resolving conflicts if it looked at some of the intermediate commits as well, but I don’t know of anything that does so.

Re: Unified versus Split Diff

#126

Post by recov »

aaaronic wrote: post #125

I feel like I used to use a tool called Beyond Compare that presented _many_ different views of a diff (and even supported N-way diffs) back around 2012.

It's still around, and still very useful for all kinds of comparisons when you need a UI https://www.scootersoftware.com/

Re: Unified versus Split Diff

#127

Post by Too »

recov wrote: post #126
aaaronic wrote: post #125

I feel like I used to use a tool called Beyond Compare that presented _many_ different views of a diff (and even supported N-way diffs) back around 2012.

It's still around, and still very useful for all kinds of comparisons when you need a UI https://www.scootersoftware.com/

It’s still around and has hardly changed one pixel since 2012!

Yet it still feels fresh and there is no competing product that can challenge them. Most other diff tools lack good merge capabilities and are subpar in multitude of other ways.

Re: Unified versus Split Diff

#128

Post by Too »

What the author wants is git blame with highlights.

IntelliJ does this very good. On the margin to your left you can see the age of each line. Recent changes - the one you are reviewing - will be be bright white, while older proven code more faded. All inside the already powerful editor you need to navigate bigger pieces of code.

Except that will not show you removed lines. Forget it, just use the diff feature.

Re: Unified versus Split Diff

#129

Post by zzzeek »

gpvos wrote: post #114

The author complains that he doesn't see all of the code, but in the first image it looks like the right-hand pane shows exactly that (though with diff highlighting). Am I missing something?

agree, I use side-by-side diff tools and the right side is where "the code" actually is. dont really get what issue the author has with this unless it's that the highlighting distracts them.

Re: Unified versus Split Diff

#130

Post by nix0n »

mi_lk wrote: post #84
knubie wrote: post #18

A third (fourth?) option worth mentioning here is difftastic[0], which uses "structural" diffing (as opposed to line diffing) for more granular diff highlighting. [0] https://github.com/Wilfred/difftastic

only side-by-side view, unfortunate for my unified view taste

It has a --display=inline option now.
Post reply on HN