How does this work for deleted lines, since these don't have a corresponding line in the "current" view.
Unified versus Split Diff
41–50 of 184 posts
Re: Unified versus Split Diff
#42Earlier quoted context omitted.
> reducing individual code ownership I am now working in an organization that is set up to reduce code ownership, and they struggle to attract talent, although pay is good and work is fulfilling. How do they do reduce individual code ownership? Horizontal integration. Developers code, analysts design DB structures (at least nominally), project managers set up meetings. Different silos exist for CICD, cloud roles, cor…
> an organization that is set up to reduce code ownership, and they struggle to attract talent These might not be related though? > work is fulfilling > It exhilarating to start projects, then see them degrade inevitably into corporate monstrosities. What you describe does not sound pleasant. So it's not fulfilling after all?
Projects are fulfilling because they have public utility.
The no individual code ownership policy is hard to bear for inquisitive minds, though.
Thus the talent shortage.
Re: Unified versus Split Diff
#43I often hear KDiff3 recommended in these cases. There are many graphical diff visualizers. I often use the ediff functions in Emacs.
Even though I'm a KDE fan, I usually use Meld for diffing, especially since I've set it up with a lot of custom filters for certain cases. However, when I want to compare 3 different files, kdiff3 is my go-to tool.
Re: Unified versus Split Diff
#44Earlier quoted context omitted.
> In my book a general code review is simple sanity check by a second pair of eyes, which can result in suggestions to use different API or use an API slightly differently. This is an impoverished view of code review. Code review is a principal mechanism for reducing individual code ownership, for propagating conventions, and for skill transfer. A good code review starts with a good PR: one that outlines what its goa…
I go back and forth on this. On the one hand, I really like constant deep feedback. I really like the consistency benefits of having another person say “that’s too much, I find that unreadable.” On the other, I have now been at a lot of places where it was very hard to get my code reviewed, latencies of days and sometimes weeks if folks are in a particularly heinous crunchtime... And then when it does get reviewed, t…
"I would have done it from this other approach". I've seen that, and it's not good when you get the feeling of "code review is when someone who hasn't thought about your problem tells you how you should have solved it". People sometimes feel they have to add value as a reviewer, and casually discarding other people's work is the way to do it. Fortunately it's not something I have to deal with at my current job.
Re: Unified versus Split Diff
#45How does this work for deleted lines, since these don't have a corresponding line in the "current" view.
Re: Unified versus Split Diff
#46Earlier quoted context omitted.
I go back and forth on this. On the one hand, I really like constant deep feedback. I really like the consistency benefits of having another person say “that’s too much, I find that unreadable.” On the other, I have now been at a lot of places where it was very hard to get my code reviewed, latencies of days and sometimes weeks if folks are in a particularly heinous crunchtime... And then when it does get reviewed, t…
This is called Continuous Integration, and its a shame that the term got nicked to now mean "that thing that builds our PRs somewhere". The idea was that everyone pushes to main all the time, which basically reduces integration time to 0, as everyone is doing it every couple of minutes on big teams. After a while you learn how to not step on people's toes (Introduce new classes incrementally, use docblocs documenting…
Everyone committing to the main branch all the time sounds like a nightmare to me, to be honest. I would probably seriously consider quitting if this was forced on me.
(Or rather, I would probably just run on my private git copy, and only pull every once in a while, and ignore that the main branch always changes.)
When / how do you do code review in your suggested workflow?
Re: Unified versus Split Diff
#47How does this work for deleted lines, since these don't have a corresponding line in the "current" view.
Like this: https://user-images.githubusercontent.com/1711539/277602101-...
I quite like your diff visualisation idea, thanks for sharing. Since I am currently working on a git client (gitbutler), I'm gonna experiment a little bit to see how it feels in practice
Re: Unified versus Split Diff
#48A 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
Thank you for sharing this project! I have been searching for something like this for some time
Re: Unified versus Split Diff
#49Earlier quoted context omitted.
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…
Maybe time to try Emacs? The diff support is great. And magit is native to Emacs.
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.
Re: Unified versus Split Diff
#50This 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 strictly a problem with the tooling, but more of culture and knowledge sharing.
And we are not going to solve it with a better tool.