• 3 Posts
  • 185 Comments
Joined 1 year ago
cake
Cake day: October 21st, 2023

help-circle

  • Even though I agree with your second edit, I have to say that the point you mentioned in the first edit is really a concern. India used to have a freeze on the ‘share’ of the national budget that each state will get. It was based on the population from the 1971 census. Now that has been changed to 2011 census data

    Even though on the periphery it may look like this is the right thing to do, the problem is much more complex and nuanced. So there have been a lot of initiatives to control population growth in India, starting from 70s and reaching the peak in 90s. Southern states were more compliant and took good initiative to create awareness and enforce other measures. This is a broad generalisation, based on the south and north dichotomy. In general many Northern states were not very keen on that.

    The problem is this resulted in a larger population growth in Northern states compared to southern states. So now when the Central Government wants to change the proportion, southern states find it unfair, because their effort in controlling the population in the past is kind of neglected. This problem gets amplified with the fact that the southern states make really good contributions to GDP.

    But at the same time, as a nation it is the responsibility of the richer states to share and help the poorer state more, and help them to grow. Without this help even measures including population control and public health, cannot be implemented.

    I think this is a bit similar to the issues in Catalonia, and Spain. They contribute much more to the GDP, but get less compared to this from the Government.

    I really don’t think there is a straightforward solution to this.










  • 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?





  • 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?