IMO the problem for developers is that they have to provide general solutions, so they have to cover each case all the time instead of just a singular case at a time.

Obligatory video when it comes to time zones: https://www.youtube.com/watch?v=-5wpm-gesOY

“But why? It both has to do with computers!” - literally a project manager at my current software project.

Pro tip: you can actually get organized in a union and strike just to get more money, no need for AI or getting fired. CEOs hate this trick!

I would never rely on the opinion of my boss when the question is what my rights are. They’re usually not a lawyer and their interests are often contrary to mine.

Yeah, you’re right, technically it’s not a “diff”, it’s the changed files.

I don’t think this technical detail has any consequences for the general mental model of Git though - as evidenced by the fact that I have been using Git for years without knowing this detail, and without any problems.

I disagree, hard.

I disagree with the general conclusion - I think it’s very easy to understand*: each repo has a graph of commits. Each commit includes the diff and metadata (like parent commits). There is a difference between you repo seeing the state of another repo (fetch) and copying commits from another repo into your repo (merge; pull is just a combination of fetch and pull). Tags are pointers to specific commits, branches are pointers to specific commits that get updated when you add a child commit to this commit. That’s a rather small set of very clear concepts for such a complex problem.

I also disagree with a lot of the reasoning. Like “If a commit has the same content but a different parent, it’s NOT the same commit” is not an “alien concept”. When I apply the same change to different parents, I end up with different versions. Which would be kinda bad for a Version Control System.

“This in turn means that you need to be comfortable and fluent in a branching many-worlds cosmology” - yes, if you need to handle different versions, you need to switch between them. That’s the complexity of what you’re doing, not the tool. And I like that Git is not trying to hide things that I need to know to understand what’s happening.

“distinguish between changes and snapshots that have the same intent and content but which are completely non-interchangeable and imply entirely different flows of historical events” How do you even end up in a situation like that? Anyway, sounds like you should be able to merge them without conflicts, if they are in fact completely interchangeable?

“The natural mental model is that names denote global identity.” Why should another repo care, which names I use? How would you even synchronize naming across different repos without adding complexity, e.g. if two devs created a branch “experimental” or “playground”. Why on earth should they be treated as the same branch?

“Git uses the cached remote content, but that’s likely out of date” I actually agree that this can lead to some errors and confusion. But automation exists - you can just fetch every x minutes.

“Branches aren’t quite branches, they’re more like little bookmark go-karts.” A dev describing what basically is just a pointer in this way leads to the suspicion that it might not be Git’s mental model that is alien.

“My favorite version of this is when the novice has followed someone’s dodgy advice to set pull.rebase = true” Maybe don’t do stupid stuff you don’t understand? We know what fetch is, we know what merge is. Pull is basically fetch & merge.

““Pull” presents the illusion that you can just ask Git to make everything okay for you” Just… what? The rest of the sentence doesn’t really fix this error in expectations.

• except the CLI of course, but I can use GUI-tools for most tasks

constantly rewrite both the code and tests as you better understand how you’re going to solve the task while trying

The tests should be decoupled from the “how” though. It’s obviously not possible to completely decouple them, but if you’re “constantly” rewriting, something is going wrong.

Brilliant talk on that topic (with slight audio problems): https://www.youtube.com/watch?v=EZ05e7EMOLM

No, they’re not. Antisemites hiding behind “we’re just criticizing Israel” does not mean everyone criticizing Israel is an antisemite.

I also doubt that a statement made by a jew can’t be antisemitic just because it was made by a jew. That’s like saying a statement can’t be misogynistic because it was made by a woman.

Isnt that also super important to include in this discussion?

It definitely is. I am arguing against comments that simplify a complex situation.

Sure Hamas is reacting violently, but that’s the only option they’re provided

I doubt it’s the only option, others have had success against colonizers using different methods. And I also doubt that this violence is improving the situation of the Palestinians in any way.

You make it sound as if there wasn’t any violence from Hamas & Co during all this. I don’t think that’s helpful in a discussion.

At least in Germany many do.

I love how it recommends paying Netflix, Disney etc. but does not mention libraries at all.

Like I said in my other replies: I am not attempting to skirt around JS. If TS is a superset of JS, it would obviously make no sense to try to avoid JS. What I’m looking for is a book/tutorial/… that is structured in a way that it teaches the most important parts the way they are used in TS (including JS) first.

Example: when functions are taught it would explain the basics of JS functions along with the parameter type annotations of TS, because that’s the way functions are used in TS.

Please see my other replies.

Yes, and I would like to learn the tightened up version rightaway ;-) When I want to learn e.g. about functions, I want to have a chapter “Fundamentals of functions” or something (and probably another chapter for advanced stuff about functions, edge cases etc.). Right now it seems like I would have to first read about functions in a JS book without knowing how they will be used best in TS). And then I would take another book and read about the modifications that TS makes to them.

I get that in order to “fully understand” TS I need to “fully understand” JS. But in the beginning I would like something that explains the core concepts of TS (which of course may and often will include JS concepts).

I know TS doesn’t remove that much from JS, but I expect the typing, structuring etc. to prevent some behavior that can occur in JS - otherwise what would be the point of e.g. the typing system? So that are the parts I don’t need to learn (at least not at first).

I think an important point for me is that I’d rather learn “from a TS perspective”, that is starting with best practices and common use cases as they appear in a TS environment. Right now it sounds to me that the usual way would be to read some JS book, where I learn e.g. about functions or objects. And then I would read another book with all the modifications that TS makes to e.g. functions or objects.

Yes, that I need to learn some amount of Javascript is a given. But I would rather not learn some JS aspects that I won’t need anyway, because TS prevents me from using them or has other best practices.

!battlebit@lemmy.ca

Two new files wouldn’t create a merge conflict though (unless they have the same name)?

What I expected when I read “Retro Handheld”.

Well, I’d like to hold government agencies to a higher standard than human traffickers. That the criminals who organize these crossings are scum isn’t really disputed by anyone.

Well, the chargers were at least a step in the right direction (though probably with the focus more on consumer friendliness than environmental impact).

And not only money - resources and energy as well.