I think I got the idea. So essentially a new copy of the file is created and stored only if there is a change, else it just refer to the older SHA. Am I right? Now I understand why LFS was needed for binaries, else it createds a lot of storage problems, but not the huge monorepos.

I’m not a developer, but a design person who covers much more including architecture. But in my org I happen to teach developers how to use Git. Strange, I know. But that is the case. It gave me a good opportunity to learn Git in depth.

I went through your blogs and patch stack workflow. I have to say that I have not been happy with the branching workflow and I always felt that is not the best (I agree to the point about “unjust popularity”). The patch stack workflow makes more sense to me. Unfortunately we won’t be able to adopt, since getting everyone to Git itself was a huge effort. Also developers are not that keen into creating good code, but just working working code. I’m extremely frustrated with that.

Also your blog design is really good. I love it. I always wanted to create something like that. But never managed to sit down and do it. Can you give me a brief about the tech stack used for the blog?

Do you use RNote for diagrams? The style looks familiar. Or is it something else?

Aah. I assumed linting was part of the build also. My bad. I did understand the idea you were mentioning. Just that assumptions kind of threw me off.

I wanted to ask something related to that. As you mentioned, git takes a snapshot of the repo on every commit. So splitting up the bug fix and other activities means you have 3 or 4 commits instead of one. Let us say we are dealing with a very large repo. This does not look ideal in that context right? So do you think the way you proposed is only suitable for smaller repos?

It was originally created for the satire book Our Dumb Century: The Onion Presents 100 Years of Headlines from America’s Finest News Source

This is some next level meta.

So this bit confuses me. The article says in the intent and scope section that the entire process of bug fixing, in the included example, is literal bug fixing, clean up toggle, correct lints, correct duplication. That point to linting issues.

The earlier section says that a commit should be ‘buildable’ and ‘testable’. So if there are linting issues, the commit won’t satisfy this criteria right?

What am I missing here?

Unfortunately that is not how those graphs are plotted.

I found this in their GitHub repo.

Just out of curiosity, and I don’t know anything about testing.

Is uuv is equivalent to Playwright + Cucumber?

Oh, I was not aware about the 2022 policy. Thanks for sharing. I completely agree with the last point that if they retain the ‘.io’, it will be a complete opposite of the written policy.

My company has a ‘.io’ domain. We have to plan for the scenario of ‘.io’ getting retired, I guess.

I don’t think that is how it works.

Some info on how these top level domains came into existence can be learned from this video

You’ll never guess the most popular internet country code

There are many ccTLD retained by ICAN after the country became non-existent. The Soviet Union is an example.

For those who are confused, the comment meant to say

52*51*50*....*3*2*1

i.e. 52 × 51 × 50 × … × 3 × 2 × 1

Markdown syntax screwed it up.

Maybe OP is part of a law enforcement entity!!

Same here. Took me some time to connect the dots.

This is a bit absurd. I really don’t think this is as serious as some comments say. Also there is a comment from AUR package manager which explains more details. . And even the blobs in the first post there are source and build instructions in their respective folder.