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

171–180 of 184 posts

Re: Unified versus Split Diff

#171

Post by eru »

jaggederest wrote: post #163
eru wrote: post #162

Earlier quoted context omitted.

Making those provisionally merge commits (and testing them) is a good idea, if you can spare the computational resources. See https://bors.tech/ for a similar idea. What I would object to is changing the 'official' master every few minutes automatically.

Yes, I would not advocate for that either. I like having PRs be a more complete thought, ideally, though sometimes you're left with 3 PRs for "one change" if you need e.g. a database change, a migration for the data, and changing the code to use the new column, which is frustrating but doable.

I'd like my PRs to tell a very sanitised story of how I could have come up with the change, with the power of foresight.

Basically, first you write your code however you see fit. Then you use git to rewrite history to make the reviewers life easy, and then you give it to the reviewer.

The reviewer doesn't need to know that my original version had a bug that I fixed later. I can make it look like I came up with a bug free version from the start.

Re: Unified versus Split Diff

#172

Post by sam_lowry_ »

ilyt wrote: post #90
sam_lowry_ wrote: post #42

Earlier quoted context omitted.

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.

You assume projects are fulfilling because they have "public utility" (whatever the fuck that means). That's your assumption, not objective fact. I would not work on boring ass project with cripping management problems and think that's fulfilling. I assume you have recruiting problems because most people share that sentiment. People like to work on interesting stuff without much office politics, that is "fulfilling"…

> That's your assumption, not objective fact.

I meant working for emeregency services, social security, global medical dossiers, etc This is objectively public utility.

Re: Unified versus Split Diff

#174

Post by jaggederest »

eru wrote: post #171
jaggederest wrote: post #163

Earlier quoted context omitted.

Yes, I would not advocate for that either. I like having PRs be a more complete thought, ideally, though sometimes you're left with 3 PRs for "one change" if you need e.g. a database change, a migration for the data, and changing the code to use the new column, which is frustrating but doable.

I'd like my PRs to tell a very sanitised story of how I could have come up with the change, with the power of foresight. Basically, first you write your code however you see fit. Then you use git to rewrite history to make the reviewers life easy, and then you give it to the reviewer. The reviewer doesn't need to know that my original version had a bug that I fixed later. I can make it look like I came up with a bug…

I used to do that but these days I prefer the whole story be in there so I can reference it later if I run into the same bug in a different place.

In general I find my past efforts to maintain a clean git history were probably not that useful, as long as you're not running e.g. 4 or 5 branches in parallel with crossing history. Branch off, make change, merge back main, PR, is fine.

Re: Unified versus Split Diff

#175

Post by exclipy »

lelanthran wrote: post #7

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?

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.

Re: Unified versus Split Diff

#176

Post by Arch-TK »

eru wrote: post #161
Arch-TK wrote: post #70

Earlier quoted context omitted.

To be fair. I have never really heard of pushing to master as a CI technique for git. You would push to your own publicly visible branch and some script would automatically attempt to merge into a CI branch unless there's merge conflicts in which case you get notified. Then as you add things you get notified if the whole thing is breaking and get made aware of upcoming issues.

If there's no merge conflict (and the tests pass), would the tool also change master to the new merge commit? Or are all the merge commits just made provisionally to inform you, but don't change master?

>would the tool also change master to the new merge commit

Not in my experience, no.

The goal is just to keep you aware of what problems you're likely to run into if you tried to push for your change to be merged in at the present moment. If these problems are due to work another team is doing the idea is then that you might begin conversations with that other team to discuss how best to sort these things out.

Re: Unified versus Split Diff

#177

Post by tome »

pmontra wrote: post #58

In my experience unified diff is good for small changes. Split diff like meld is good for many changes in a long file. Many diffs in a long long file, you should not have such a file. For large PRs with many files the problem is not so big because they are the sum of many small changes, file by file. Maybe a team should aim at small PRs but sometimes having to change X into Y everywhere, with a large X or Y, is an in…

Interesting. Seems to be the exact opposite preference to https://news.ycombinator.com/item?id=37997203!

Re: Unified versus Split Diff

#179

Post by kerneis »

JNRowe wrote: post #33

That kinda feels like how I review with vim. * A little scripting around opening the PR, which basically performs a "vimdiff baseref : file ) file "-style dance on the changes(see :h diff). Using vim's tabs is great for this as they're really only views, so you can hold individual buffers open in distinct states at the same time. * Scroll locking still works as expected in the main view, but you can avoid it in a sep…

What do you mean exactly by "push as a comment" and "pulls text comments"? Is it some sort of custom logic specific to your work place?

Re: Unified versus Split Diff

#180

Post by samus »

Zababa wrote: post #169
samus wrote: post #132

Earlier quoted context omitted.

It works well if the tasks are short and well-described. Long, complicated tasks descend into odysseys where one person zones out or gets completely lost as the other person just ends up treating them as a clumsy proxy for the IDE. Furthermore, it rarely works online.

That is my experience as well. Another case where the "clumsy proxy" issue happens is when I help a frontend dev debug something with the backend, especially online. Do collaborative IDEs exist? How usable are they? A collaborative terminal might be useful too (for when I want to run a few commands quickly to check something on my colleague's computer). Thinking about what I just wrote, maybe I could ssh into their m…

People doubtlessly do it. I sometimes do it when I tutor somebody on a server we both access via SSH. If you use such a server as a jump server, you can setup SSH tunnels to get all the way to another desktop.

I think it would be wonderful to install a remote IDE with workspace on a remote server. Or to VNC/RDP into one.

Post reply on HN