rich-tea

You may well be right. I probably only notice it with software because that's what I do every day.

Unfortunately this article, like almost all others, is still wrong because it looks like commits get mutated when you rebase and the old commits disappear.

It is very important to understand that commits (in fact, all blobs) are immutable in git. You can only make new things. You can't modify old things. Git doesn't delete anything for a while either.

That's because a file system is something you already understand, even if you've never actually used an old fashioned paper filing system. The software is providing you with something you understand.

Git is not providing you with something you understand. It is providing you with a DAG and you neither understand what that is or why you need it. The DAG is not the "internals of git". This is the big mistake. It is git. Everything about git is about building that DAG.

You're actually getting at something deeper which I've been noticing more and more lately. Many people seem really reluctant to learn how to use things. It only seems to happen with software. They see a program or a new language and seem to think "well, I'm already a coder, I should be able to use this". When it's even slightly different to what they expect they complain that it's "hard".

It's really strange to me. Imagine if people did that outside of software. I can already walk so I must be able to ride a bike. I can speak English, so I must be able to speak French. The same goes for software. I spent years trying to understand infix notation and learning the precedence rules. Why would it not take time and effort to learn prefix notation?

Git is not hard. It's very simple. But people learn it the wrong way. You have to learn it from the DAG up. If you cannot grasp how the DAG works you'll forever be reading and writing articles like this one which do not help you to learn.

This is a horrible article. You should not bookmark it or use it. If you're not a programmer, you shouldn't use git. If you are a programmer, do yourself a favour and spend a day going through something like this: https://wyag.thb.lt/

It will make you better at git and better at programming. Git is a powerful tool and you need to learn how to use it. Imagine if people read articles like this one instead of learning how to drive.

I refer you to the children's story "Crying Wolf".

I actually thought the flag code disallowed flying the flag in bad weather. But I'm now unable to find any confirmation of that.

It can contain a link to the list of all invoices. So you could have /customer/<cid>/invoice which lists all invoices for the customer which are actually just links of the form /customer/<cid>/invoice/<iid>

Is that based on the size of the vehicle? In my country it is not. It is only based on emissions. Some SUVs will pay less tax than a small sports car.

You gained the ability to find the invoice. There is no need to have customer id in the invoice url. Just /invoice/invoice_id is enough.

> When it storms and gets wet, it’s all I can hear inside my house.

Isn't that illegal?

I agree but I'd also like to see tax paid on size of the vehicle because it's literally using more of the public highway. So motorbikes would still pay less, probably.

The SUV users say it improves safety. OK, they can pay for it.

There shouldn't be separate endpoints that take an owner's ID. That's bad design. The owner endpoint should contain a list of invoices, ie. links to the invoice endpoint.

Indeed. Hyperlinked serialisers are built in and super easy to use. And it makes so much sense when you use DRF's API browser too.

Why does every docker image build have to pull the packages? Are you force rebuilding and defeating docker's cache mechanism?

As usual it will take a disaster for people to realise it was a bad idea. Microsoft tried to destroy Linux in the past. Literally. Linux is what gave us git in the first place, and docker, and so much technology that we love today. Oh how quickly the past is forgotten when convenience is on the table.

All of these advantages don't make sense if half your commits are broken versions of the software. Rebasing helps ensure that each commit is valid. That's important for the reasons you mention. Having a log of what you actually did is not important.

I'm not talking about squashing the feature branch. I'm talking about squashing all of master down to one commit (initial commit). If you don't take care of your history, my question is why do you keep it at all?

What do you use your git history for? History is either worth keeping, in which case you should maintain it like any other artifact, or it's not, in which case you should squash down master to a single commit every time you merge.

But maybe you use your history for something else that I haven't considered.

What I really like to do is make actual fixup (or squash) commits during a code review and just push these to the branch normally. That way reviewers can easily keep up with the changes. Right at the end, the maintainer requests that the original developer does a rebase --autosquash before the branch is actually merged.

This works really well but I rarely see people talk about it. It means you don't have to use something complicated like github or gitlab to keep up with rebases. It works for everyone.

Oh, so your point is that bitcoin-specific problems aren't a problem outside of Bitcoin. Gotcha.

I've read two pages of the article and I've still no idea what it's talking about. They're clearly going for the "shrouded in mystery" marketing approach, but I haven't got time for that.

Can the title be updated to describe what this is actually about rather than just having the name of an almond-based confectionery item?

How is it disingenuous? You said that heists were "vanishingly rare" outside of Bitcoin.

As it happens, your cash in the bank is being slowly devalued via inflation as the banks are constantly making new money in the form of loans.

Bitcoin being the way it is is a feature, not a bug. If you don't get it, that's fine, but don't make ridiculous claims like only bitcoin is susceptible to crime and incompetence.

Really?

https://news.google.com/search?q=Theft+stolen+-bitcoin

Name a technology that isn't susceptible to crooks or incompetence. Bitcoin isn't worse than anything else in that respect.

The UK has the "fit for purpose" clause in the Distance Selling Act and I think you can return the product at any time. I'd highly encourage anyone who is inconvenienced by this to exercise such laws.

I was going to say I fondly remember PowerToys on Windows XP, but it looks like it actually goes back to 95. They were always one of the first things I installed after a regular reinstallation of Windows.

Later I switched to Linux and realised most of it was already built in or unnecessary and, needless to say, regular reinstallations are no longer a thing for me.

What's your point? I didn't say anything about what HN is, I just said that it is in no way a "diverse" group of people. Honestly can't see how anyone could think this is diverse.

Risks to other people is also known as responsibility and that should also be accounted for. But sometimes there is an imbalance. You can be putting others at risk but not be properly considered responsible. I think there is a lot of that in software, particularly when people's privacy/data is at risk.

Personal risk is a bit different because everyone has a choice about what is acceptable for them. Risk to others should not be your choice. The responsibility should be fixed and defined and therefore it's probably easier to make logical arguments about compensation rates.

> Not sure who 'us' is; HN readership is pretty diverse

Do you really believe that? 99% of us work in offices. You're in a bit of a bubble. Try going to a working man's club or the equivalent in your country to get a glimpse of the rest of society.