A New Git Diff Algo

[@UnknownUser-mj8rg]

THE 2012 VI DATE IS FROM THE LEAGUE OF LEGENDS CHARACTER

[@arijanj]

oh my god

[@Karurosagu]

* facepalm *

[@katzetante5599]

lmao

[@dragons_advocate]

Whaaahahaha!

[@Kynatosh]

Bruuhhh

[@illesizs]

*Diff tool:* Don't worry about this line, only the whitespaces changed here... *Python:* The what?! 😡

[@kuhluhOG]

*Whitespace*: Yeah, about that.

[@vidal9747]

Fortran fixed form: first time?

[@cefcephatus]

Don't worry about this 4 spaces-tab. Meanwhile, your editor uses literal tabs.

[@monad_tcp]

Diff tools are stupid because we want to diff AST , not whitespace. Can they fix the problem when I just move a function from the bottom of the file to the top, that's not a meaningful difference, don't show it.

[@Luclecool123]

markdown

[@JorgetePanete]

10/10 journalism, would release vi in 2012 again.

[@jan_harald]

allegedly it's the date of the character from league of legends, the author does not give even a fart, not to mention a shit

[@unicorn_tamer]

@@jan_harald yeah I googled it and that was the first result lmao. That's some real factchecking being done here

[@auscompgeek]

The fact the entire article doesn't mention the 4 different diff algorithms in git diff, the ignore whitespace options, and the colour moved option boggles my mind.

[@MrRoboticBrain]

Not to forget the word boundary options: i have aliases to add --word-diff-regex='.' to highlight things like single character changes.

[@jan_harald]

allegedly the date 2012 date for vi is the date of the character from league of legends, the author does not give even a fart, not to mention a shit, just have AI write the slop sponsored article

[@monad_tcp]

classic academia

[@thekwoka4707]

@@jan_harald could be a quick inattentive human mistake, especially if they don't know that VI is a character. Most of the results for VI are GTA VI or League.

[@ulidtko]

Such a thorough and unbiased "research", didn't even spot diff.colormoved=zebra in the freaking git config manpage

[@esquilo_atomico]

looool the guy that said that 2012 vi date is from the lol character is absolutely correct !!! these guys trust ai too much

[@monad_tcp]

so you're saying that was not intentionally put there by a cringe millennial ?

[@nephatrine]

@@monad_tcp as a cringe millennial, I can confidently state it could not have just been a reference from a cringe human of any kind.

[@jose6183]

I'm older than Vi now. What a time to be alive

[@luigidabro]

You just became older than vi while watching this video

[@jkdmyrs]

Stopped the video when the author said vi was from 2012. Nothing against prime, just not gonna listen to him read a garbage article

[@Karurosagu]

he should've stopped reading right there

[@BearlyWorkingDev]

it's a league of legends reference lmfao

[@vidal9747]

Just a joke.

[@jkdmyrs]

@@vidal9747 it wasn’t a joke, it was the author being dumb/relying on AI.

[@vidal9747]

@@jkdmyrs Wasn't it a LOL reference?

[@DataScienceDIY]

Should have started with: This is an ad for GitClear

[@jan_harald]

and also an undisclosed AI that wrote half the article

[@connormc711]

Yeah and also diff looks like trash not sure it’s a good sale

[@martinkrauser4029]

Wouldn't say it's exactly an ad :D

[@defenestrated23]

The advantage of the old Meyers diff is it flags every part of the code that gets touched, so it gives the reviewer more context. In most code, the state is contextual. I've had diffs which were a single character and I basically had to re-read the whole file to mentally model the side effects. Otoh, MOST diffs are pretty straightforword and the new fancy diff algos are much nicer to look at. Just let the developer choose and switch between em.

[@jan_harald]

tbh, it'd be kinda easy to do three actions, with actual benefit (imho) + green add - red remove * blue move (perhaps dark blue for the removed block and light blue for added block or like, orange delete and blue add, instead of red/green?) it would work well in the "old" style but yeah, the way they're doing it, is anything but clear

[@TheAutoBeef]

vim users are "developers from certain generation" i'm 23 y.o, learned how to seriously program a year ago. using vim and nvim at my job, of which most of the codebase is in c.

[@InDieTasten]

stop lying about your age, grandpa!

[@da40au40]

Let me guess you have 2 open source operating systems, 1 c compiler and have contributed vastly to the unix os am I right???

[@Luiz997488]

Congrats

[@mattymattffs]

I'm sorry to hear that

[@hypermiraclepositivegirl2415]

What work do you do?

[@AScribblingTurtle]

1:48: Not even two minutes in and I want to scream until my vocal cords give out. If that's the level of "Investigation" we can expect from future Journalists, humanity is doomed. Googles second answer says, that Vi was released 2012. "VI" the LoL character that is. 🤦🏼

[@airkami]

This fact was released in the comments over an hour ago

[@AScribblingTurtle]

@@airkami And the problem with that is?

[@TroubleChute]

The AI plague runs deep... Developers improve software years before it's first appearance. Brilliant.

[@jan_harald]

the funniest part is apparently that's the year character named "vi" got added to game called league of legends which shows how it's likely like 50% just unfiltered ai crap indeed, lol

[@thekwoka4707]

@@jan_harald its the second result on google for me (League) while the first is the editor. Even a human could make that mistake if they get served that first and only scan it quickly. Maybe AI, or maybe just quick human.

[@notusingmyrealnamegoogle6232]

@@thekwoka4707 any human this stupid is not worth reading output from either

[@Yay295]

Do they not know that GitHub has a checkbox to hide whitespace changes?

[@chris-pee]

That checkbox only works in specific cases - if the only thing that was added/removed on a line was a whitespace. It doesn't when you, for example, split a long line of parameters to multiple lines - I'd say that's a whitespace change, but github disagrees and shows all those lines as modified.

[@notuxnobux]

@@chris-pee Right, but the article is dishonest since in the example is hows there are lines with only whitespace changes but it doesn't show the git diff with that option selected. It shows the worst case scenario of git diff by using the worst option vs the best case scenario of the software/service they are promoting

[@chris-pee]

@@notuxnobux well yeah, the quality of example matches the overall quality of the article and their research

[@Spiker985Studios]

Git != GitHub However, git diff does have options for ignoring or controlling whitespace inclusions

[@ulidtko]

git config --global diff.colormoved zebra

[@thatryanp]

Ternary rage, ASMR, research quality control, all in the time it takes to review one PR 👏

[@calebmcnevin]

This is the most smooth brained article I've seen in a while. "Companies that have more lines of code to review spend more time on code reviews. Obviously the answer is fewer lines visible in the code review, then they'll spend less time reviewing!" Classic correlation vs causation. Why don't we do code reviews where we don't even highlight any diffs? We'll be so much faster!

[@raph151515]

they have a point on the size of the team, because tech leads fail to adapt the proper review dispatching depending on the team size. I've seen a team where all the PRs were assigned to all developer (10+) since this methodology is exponential, the idea success only depends on the team size. Nobody felt assigned, attendance was random, some average PRs were massacred by the reviewer(s) and some critical huge broken PRs were completely ignored. He highlight this phenomenon because of the stats numbers, these numbers show a trend that the industry can't account for volume difference when designing a dispatch / rules methodology.

[@Kane0123]

7:48 surprised the article doesn’t talk about the origins of Ruby from 2500bc when it was likely first discovered.

[@chris-pee]

I'd just like to give a shout-out to existing tools that provide semantic diffing: diffsitter, difftastic, and SemanticDiff. Diffsitter (and difftastic I think) uses treesitter, to a quite interesting effect.

[@0M9H4X_Neckbeard]

I've been using delta for many years

[@thingsiplay]

BTW wouldn't it make more sense to have different algorithm depending on the language style? Such as Python and C should be reviewed differently and not by same algorithm.

[@chris-pee]

@@thingsiplay Yep, all existing semantic diff tools have a set of supported languages, that are implemented somewhat separately.

[@orsted4670]

I think detecting moves and copy in the diffs would be really useful in refactoring changes but I couldn’t understand how they are representing the information on those cases.

[@jan_harald]

tbh, it'd be kinda easy to do, for three actions + green add - red remove * blue move (perhaps dark blue for the removed block and light blue for added block) would work well in the "old" style but yeah, the way they're doing it, is anything but clear

[@XxZeldaxXXxLinkxX]

​@@jan_harald > Be none-colorblind

[@wetfloo]

​@@XxZeldaxXXxLinkxXhave customizable colors like gitlab has it, problem solved(?)

[@Jim202030]

Management is 100% the problem today.

[@meggawatts]

9:03 When I do code reviews of my colleagues, the lines of code that changed are usually not the part that needs a review. We're all professionals, and can write correct code. What needs review is the blast radius outside of your changes. What's the point? With the old diff, we can see that the new changes had an effect on the old code as well. The old color diff very clearly shows the scope change, where their new style kind of obscures it.

[@jan_harald]

tbh, it'd be kinda easy to do three actions, and that would have actual value, + green add - red remove * blue move (perhaps dark blue for the removed block and light blue for added block? or red delete and blue instead of green, for add?) would work well in the "old" style but yeah, the way they're doing it, is anything but clear

[@masterflitzer]

​@@jan_harald yeah i thought the same, that would improve the review experience by far

[@MichaelCampbell01]

The git CLI has a variety of diff algo's to choose from; it's weird github wouldn't let you also choose them to get some parity with `git diff` locally.

[@Raven-rv9jr]

honestly this article fails to understand that you can do code reviews locally outside of like GitHub.

[@pythagoran]

18:13 best HR session of all time

[@autohmae]

The people working on this need to learn from the original web diff tools and Meld and Kdiff3 how to do the coloring, they clearly have no idea what they are doing. Hint: use background colors

[@illesizs]

*Review comment:* "looks good" _Approved_

[@mattymattffs]

Honestly, consistency is the only argument for formatters and linters. Formatting is completely irrelevant. However, consistency in formatting across an entire project and potentially multiple projects in your company makes it easier to onboard people. It seems crazy, but if someone learns a style from one area and then can apply that same style everywhere it does actually help.

[@squishy-tomato]

formatting does help with readability, it's not just a matter of consistency.

[@barbacastagne5752]

"What did the five ternary say to the face?". That's poetry, well done!

[@bitti1975]

The main purpose of code reviews is not catching bugs/defects. That may happen, although mostly by accident. The main advantage is knowledge sharing, making code more clear/understandable, point out missing test coverage, apply a common standard to the code base and across projects, etc. Of course, this will also lead to lesser bugs and defects in the middle and long run, but don't expect to catch them during a review.

[@mattymattffs]

Hard disagree. The main purpose is to see if the code actually solves the issue.

[@bitti1975]

​@@mattymattffs That's often the most trivial part, though (if the PR is properly sized and doesn't try to do too many things at once, which would also be something which can be pointed out at a code review). And the product owner or customer will find it out anyway if it doesn't. There are a million ways to 'solve' an issue, but there is a big difference between a proper solution and something hacked together. In fact, that's an argument against code reviews: who cares about code quality as long as I get the feature I wanted?

[@marcr8181]

There's a gazillion git clients out there and a lot of them already have an improved diff visualization where you can switch between multiple different views. Does not using proper tooling while it already exists fall into the category of skill issue?

[@airkami]

Knowledge issue

[@Destros1]

Crazy how the first 4 comments are bots

[@abhinavrobinson2310]

They took our “First” 🥲

[@DKRYMMA]

Crazy how you would claim to have far more relevant intelligence to the subject than the bots yet still offered about the same amount of valuable inputs

[@jkdmyrs]

⁠@@DKRYMMAcrazy how he NEVER claimed to have more relevant intelligence. Crazy how you’re just a troll that literally makes shit up. Probably a bot yourself.

[@Destros1]

@@DKRYMMAdid that make you feel better?

[@madskaddie]

42:00 - "when people talk about like having maintainable and readable code what they are saying is that you need to write it the way I want to see. " This is when I stand up and bow to prime

[@UnemployMan396-xd7ov]

The bot is crazy 💀

[@kibels894]

2012 vi is a wild mistake to have in a tech article lmao

[@jan_harald]

it's the release of the character "vi" from league of legends, which makes it doubly hilarious

[@dennisestenson7820]

It's an ad, not an article.

[@Exilum]

I think they are not trying to show that their version catches more bugs but that it's faster to gain the same understanding. What they've shown is a statistically insignificant difference in question accuracy (a metric for understanding pull requests) with a statistically significant gain in speed. So their metric is not actually measuring whether bugs were found but whether after they're done with their review, developers can answer questions about the pull request that show they understood what happened.

[@mattymattffs]

I don't want better tools for me to be able to review, because I have to review in context anyway. The current diff perfectly lets me do that and I don't need to think twice about it. It is intuitive. It is simple. What I want is better merging so that I don't have any conflicts and don't need to manually merge. That's it

[@climate_sentry_123]

JetBrains made Git Diff looking much better - you can see individual chunks of changes within a line. And that's what missing here from presentation of capabilities of the new method. That's what made it look worse. Keeping context isalso important, but that also is just a setting of how you present/view results of diff - not the algo itself.

[@population-pyramid]

Reminds me of the old reliable icdiff, can't live without it.

[@Xehlwan]

The article may be bad, but the actual diff algorithm looks interesting. Showing that a line was modified or moved instead of pretending that we just deleted and added new lines is an improvement. What needs to be proven is that the "smarter" diff doesn't lie to us when changes get complicated.

[@tutacat]

research is actually a peer reviewed research paper. that doesn't mean perfect, but just the best way we have so far. this is a study, their own internal research, not a research paper

[@ivanheffner2587]

A whole lot of folks have a serious skill deficiency when it comes to ternaries. The amount of rage is ridiculous and should be reserved for things that really deserve it, like Nano.

[@Luclecool123]

dart format got it right

[@madhuguru3130]

They made a fundamental math error: 29% extra lines to review != 29% less lines to review going in the other direction... it is 22% I am referring to the "changed lines" comparison between commit cruncher and Myers that prime is discussing @ 25:05

[@teppich626]

the ternary breakdown is peak content

[@BloodyxScy]

16:00 That was a personal attack D:

[@masterflitzer]

but 100% justified

[@MichaelZijlstra]

Worth watching just for the rage on nested ternary expressions

[@danhorus]

I like the way Azure DevOps Repos presents diffs. If a file is renamed, it tags that as a rename rather than showing one file deleted and another file created. Even if I change the code after renaming the file, it still detects the rename and shows the diff compared to the original file. This is really helpful. There's still room for improvement, though. If we reorder objects in a JSON array, it still can't recognize that as a move rather than a deletion of some lines and insertion of other lines. To properly review these types of changes, I need to copy the before and after files into another diff tool that can understand JSON a bit better.

[@WaterGame7777]

Never thought when I subscribed I would end up hearing smoothie ASMR.....

[@Imperial_Squid]

18:49 what's absolutely wild about that ternary operator thing is that it's functionally the same number of linesand strictly worse syntax msg = i % 3 == 0 ? // fizz : i % 5 == 0 ? // buzz : // msg if (i % 3 == 0) { // fizz } else if (i % 5 == 0) { // buzz } else { // msg }

[@jan_harald]

it is useful in some cases, like oneliners but at the point you're splitting the lines for syntax ANYWAY, it's indeed, just worse I believe ternary is a minuscule amount faster, but it'd be pretty negligible

[@-_James_-]

I would argue putting else after a closing brace and opening braces on the same line are no better, syntactically speaking.

[@Imperial_Squid]

@@-_James_- you'd be wrong

[@-_James_-]

@@Imperial_Squid You've never had to deal with two-space indentation with nested IFs and ELSE IFs. The ELSE after the } aligns with any IF above. Totally confusing for absolutely no benefit.

[@Imperial_Squid]

@@-_James_- reads perfectly well to me if (cond) { if (cond) { statement } else if (cond) { statement } } else { statement }

[@mdlamar]

Even if it's technically better or serves the greater good, there's a long period of transition where no one knows what the fuck is going on because their diffs look totally different than they used to. Is the savings even worth that little period, let alone calculating long term.

[@MikkoRantalainen]

26:00 I have to agree that the suggested metric doesn't make sense. Basic diff has just two operators: remove line or add a line. When you read diff, red lines have been removed, green lines have been added. Really simple. This new improved format may reduce number of lines slightly but in return you get a LOT more complex operators. Instead of thinking "is this line red or green?" I have to think "is this line deleted, added, moved, copied or just white-space adjusted?" - for *every single line of code* repeatedly. I think having a normal diff *reader* that supports "Identical segments with more than 5 lines are collapsed by default and rendered with summary "Moved function XYZ". That is, an improved tool for *reading* the existing diffs would be much superior method. I think the whole stuff was designed by a non-programmer who totally failed to understand what actually matters. If I were interested in lines of text, I wouldn't use 15 line context for my diffs.

[@superjugy]

To be fair, the fact that they were pushing the "less time reviewing means more time coding!" obviously for VPs, took away from the message. I am the kind of person that when touching code to fix something, I like to refactor other pieces to make it clearer. This means I often reorder functions, rename files and other similar tasks that make perfect sense in my head. But when I see the diff of my changes, it is pure chaos, half my files are just red/green all over and looked as if I had rewritten the entire class, and the other half are deletions and adds of new files that since I changed a little no longer recognizes it as the same file. I think this algorithm that detects reordering of functions (even across files) copy/pastes of codes and such is really valuable, simply because it is more information, BUT, like you said, more information by itself is useless if it is not understandable. So this will be great IF AND ONLY IF, the UI can find meaningful ways to use the information. For example add filters like "hide moved code" or "hide copy and pasted code". Or maybe if code is marked as moved, make it clickable so it takes you from where it was moved from. If the UI can help you understand the changes, it would be great. It is the same argument as using Vim. It is supposed to be faster because it uses less memory and stuff, but it is completely useless if you don't know how to use it or even how to freaking close vim!

[@0xCAFEF00D]

14:29 I'm all for virtual formatting and whitespace insignificance. Because then you don't have to bother with what other people think. You just get your code-style. And if you're a loon that, for example, changes function argument names to make them line up nicely when broken up on multiple lines then you're just not allowed to write code.

[@MichaelM-hj2mx]

the ternary part ... chef kiss

[@MrHuweii]

You had me at the ternary slap. 👋 😂

[@TheNewton]

All I learned from this is we need world heritage projects commits that are famous enough that this type of research references those commits because enough people in soft-dev are familiar with theme they make sense to be used in the visual references comparing diff algorithms.

[@danielvaughn4551]

The question around the 9 minute mark is actually pretty interesting. If the diffs are based on tree-sitter, you could probably display a more concise representation of the change, because tree-sitter's incremental parser algorithm is based on analyzing the changes to the AST, not the raw text.

[@chris-pee]

@@danielvaughn4551 that's what diffsitter does, but from what I've seen the reception was mixed

[@danielvaughn4551]

@@chris-pee interesting, I'll check it out thanks

[@CZiNTrPT]

​@@danielvaughn4551also Check Out difftastic

[@drxyd]

The thing that trips me up about formatters is that people try to be consistently opinionated rather than optimizing for something objective like eligibility, considering all the hours we spend reading code that seems like an awful way to go about things. We pick fonts based on how easy to read they are, the same principle should dictate how code is formatted and factored modulo performance considerations.

[@JoeStuffzAlt]

Reminds me the founder of StackOverflow was a proponent for Cracking the Coding Interview Interviewing

I love the "semantic merge" from PlasticSCM I wish git has something like that.

[@colinmaharaj50]

Went the Borland Wall fell, I went to Embarcadero for my tools.

[@Direkin]

vi 2012? I've used that when I first started using linux in the 90s.

[@paulosa1221]

The reason they said VI released in 2012 is because the League of Legends VI released that year, good ol' AI

[@jan_harald]

WE ARE SUPPOSED TO BRING CHAOS, from ORDER....wait....

[@Sancarn]

NGL I think this is actually a good idea on the whole. The changes they've added seem reasonable imo. It won't work in all situations but I definitely would prefer my open source repos commit history had some of these changes

[@jean-michelgilbert8136]

I'd go with the GitClear semantic diff any day over classic diff. Whenever I use diff programs that offer the option to use improved algorithms, highlighting of line diffs, and also moved block detection (like WinMerge), it makes reviewing changes 10 times faster compared to dumb line deletion followed by line addition to represent a line edit.

[@jean-michelgilbert8136]

So in case nobody noticed, one of the key points in that comment is that GitClear's commit cruncher is not a new idea. I've been using a version of the same thing in WinMerge for years already.

[@RichardJActon]

Some of this would be nice as alternative view options, so that you are clear on what semantics apply to the view of the diff that you are generating

[@zubinjain8675]

I think having the GitClear view as a switchable tab (the way github does for side-by-side vs unified view) would be quite helpful. I work mostly in Java, and renaming of method names throughout the codebase is frequent. As is reorganising of imports (which occurs bcoz my team members use different IDEs as per their comfort, and both have different conventions about how to order the lines in case of auto import). I suppose the potential brevity offerd by copy-paste and move classifications will be pretty useful. Regardless, developer brains will need some recalibration to get proficient with GitClear.

[@Mglunafh]

25:38 -- "Flip!" And he took it out.

[@markuss-n5i]

10:10 I don't want to see what was copied, but I don't want to see changes if new code was added at the top.

[@Jwareness]

I have a use case where such a diff algorithm could actually make a sense and save a lot of time, but their diff algorithm is part of their own proprietary paid service which they are trying to sell with this article, so I'll have to wait until someone creates an open source alternative to this, or eventually implement my own improved algorithm instead.

[@jcollins519]

It's like the levenstein edit distance algo. Some dynamic programming thing 3:01

[@abtix]

18:07 Besides the fact that this should literally be forbidden, the prettier version is WAY better to understand, I actually couldn't keep track of the if and elses in the previous one, but this one is more manageable.

[@canadiannomad4088]

I think instead of pushing everyone to use a single format, a shared code formatter should be used for git commits only. The workflow would assume that the IDE / GitHub UI will use whatever formatting that the user likes. A suitable shared format would have to be used for git/diff but that should be hidden from the user via UIs.

[@saryakan]

If PR reviews are one of the most concentration and WP needy tasks right now, then I don't think reducing the amount of is by increasing the complexity of it makes sense. I think there are three categories of reviews: 1. The one where you don't even really read the code and just "lgtm" => You won't reduce time in this category. (We all have don this, let's be truthful here.) 2. The one where you kind of browse through, sort of review everything but don't really look for bugs and just comment if anything glaring jumps out to you. => Here you'll get a reduction probably. 3. The one where you ACTUALLY review and understand the code and actively look for bugs. => If not taking longer, this might become more difficult and require more focus than before. A change like this might lead to actually improved times and money spent on developers because it reduces time in on category and makes one category more difficult, thus increasing the amount of times where people opt to just drop a category and do a lazy job. So where research would really be needed is if this saving in time goes hand-in-hand with a reduction of the quality of the PR process. Cause you could save EVEN more time, by simple not reviewing code at all, wouldn't that be wonderful, huh?

[@axaide4210]

I think the idea is good but the UI is trash. I think using github's diff viewer is not built for this density of information. If they separated some of the information out of the text, and maybe included an overlay or a second panel to display additional information it would be a lot clearer.

[@Jabberwockybird]

Ensh!tification is coming for git. If it aint broke don't fix it.

[@chrism3790]

A real big brain diff algo would be one that just says everyone is the same, so you have to review zero lines of code.

[@24wherath36]

I want a versioning system that is language aware, just removes all formatting because it only cares about the syntax, then when you clone the repo it gets formatted to your liking. If there is a web interface like github you should be able to specify how you want it formatted or there should at least be a default formatter for the web interface. Then the versioning system can diff based on the syntax, and strip out the formatting when you send in a pull request for example. Everyone views their preferred formatting, and everyone can be happy. Then Carl can have his weird ass formatting that he is insistent that everyone needs to use because that's what he's used to and it wont affect anyone else.

[@raph151515]

we need ast based diff in versioning. With AI we could even go one step further and do an intention based diff too where changes in specs would be treated differently than debugging or optimizing and the appropriate block would be selected as source of the diff. Formatter should not cover all the format, because format can be information, some specific manual format should be kept, within a limit

[@cheako91155]

I would order stuff, add blank lines or extra spaces to force the diff output in my commits to be pretty.

[@philipoakley5498]

Those bits in the middle where there's a rant about coding styles, and then later the rant/comment that the new diff method has 'heuristics' that can be iteratively tuned with the same human/individual bias arguments. This suggests that the two aspects should be combined into a single linter/diff "set of rules" that then reflect across the two similar lowest common denominator that everyone sticks to. As a matched pair the coding and docs become easier to manage. The rules become part of a broader 'linting' code that not only picks out 'poor' formatting, but also implicit low contention differences (it's all just tabs and white space differences!) Even Git itself (it's code) has clang-format to check coding style issues in new code added.

[@Ruzgfpegk]

The idea is not bad in itself, I'd like to have that AS AN OPTION, the same way way people can choose to either merge or rebase.

[@carl-henrikkristoffersen2313]

16:48 if Michael Scott was a software engineer and Toby submitted a PR.

[@youcefmoukeut6818]

The HR bit is hilarious 😂😂

[@nescafezos4265]

I personally find 2 columns diff view (like in jetbrains editor) much more clear. for me when "before" and "after" merged into 1 column is too hard to track and read code to see what the change was

[@BLiu1]

20:25 cracked me up!

[@br3nto]

8:39 the code is indented and wrapped in a `do` block. The indented code doesn’t look like it’s changed. Or maybe it has. It’s demonstrating how structural changes mixed with code changes are hard to rationalise and review. I don’t understand why the new method doesn’t indicate the added whitespace on the indented lines.

[@robchr]

A chain of 'if, else if, else' is the same as a chain of ternaries. But yeah, they can be difficult to parse for a dyslexic.

[@-_James_-]

Git: There are conflicts in this file. Perforce Merge: Umm, no. No there aren't. This file is fine. If Git wasn't free nobody would use it. But you get what you pay for, I guess.

[@pedrojuglar]

In tech, age is just a number.

[@jean-michelgilbert8136]

Thankfully it's not true that every single company herded to git. Git is an awful source control with barbaric commands that was designed for a very specific use case : the Linux kernel. If it had had some thought put in the UX then the naming of the commands would make sense and they would have similar names to the ones in every other source control tool out there. Personally, I wouldn't give up Perforce for any amount of money. Ok maybe, a few millions a year would do it.

[@daveanandmannie142]

I wholeheartedly believe Mr. Flip can do, has done and will do no wrong.

[@kausthubkrishnamurthy2410]

So TL;DR: they're following the same assumptions that people use when they say "shorter functions are easier to understand".

[@comosaycomosah]

bots suck eggs ❤🍒🍒🍓🥚🥚🥚🥚

[@mulllhausen]

The main thing to discuss here is bitbucket's broken git diff that uses double dot instead of triple dot.

[@alexmipego]

I've this idea/concept for a while… why are we still using basic text files at all (for coding)? There are many obvious uses for "not just text" files, which today are handled by syntax highlighters, doc parsers, etc… But those tools are still extremely limited - while some can already be perfect as-is. After there's the "next step" which we can simplify to as AST graph, ie we can store objects (classes, functions, individually). Imagine opening "api/users.file," and you get multiple "views"/"contexts" like Model View Controller, each showing you the functions used, but you're able to quickly search/filter in a way you're no working on a file, you're editing a spreedsheet cell that can be moved at anytime. But also where today you would have some strange comment, you could put a calculator widget to calculate something. HTML but for code files, basically.

[@unitythemaker]

I think what we need is a LSP based diff tool.

[@tutacat]

22:20 It's not 480P, that is just the state of Windows text rendering these days. We shall pray for them.

[@minastaros]

Multiple ternaries _can_ be great when they serve as a two-column table: but *_only_* when the "ifs" are small and similar, and the "thens" be simple (plain values) *AND* when ? and : are strictly vertically aligned (to show the table _grid_ ). Then they can optically present the _information_ better than if-elseif-elseif or switch-case-break constructs. This, however, requires that inner-line whitespace must be retained, and why I hate auto-formatters, too.

[@cannaroe1213]

Imagine having a problem with prettier 3.1 when prettier 3.2 is right on the horizon. shit's gonna be so pretty, i'm gonna hang FizzBuzz on my wall.