Hacker News Reader

Comment by Lutger | Hacker News Reader

Nice. But technically its true. origin/master is not master on origin. It just refers to the last known commit pointed to by origin/master, which gets updated when you fetch (pull automatically fetches).

ls -l .git/refs/remotes/origin/master

origin/master is just a file on your system, you can see when it has been changed. It doesn't magically get updated. Do `git fetch origin` and if there are any changes, you'll see the timestamp change, and the contents:

cat .git/refs/remotes/origin/master

The basics of git are so simple, you can implement the core data structures and some operations in a day. It is really worth it to get to know these.

Somehow git has managed to create a very complex user interface on top of quite a simple core.

View on HN

> But technically its true.

Is it though?

Consider a bank telling a store I am buying things at "This person has has €450 in their bank account", when at that moment I have €310. The store would be rightfully pissed at the bank for effectively lying when it is made clear later on that the transaction could not be completed and the bank answers "well, the person had €450 a few days prior to you asking us".

Without an explicit temporal information it is explicitly now.

Without an explicit status on sync status it is implicitly saying sync is up-to-date.

It's a lie of omission.

>It's a lie of omission.

but it's not?

if you have an old bank receipt that says you have $450 in your account, but you actually have $310, you need to "get" a new receipt that has the newest value.

you do that by issuing git fetch origin. then you can git merge origin/master to make everything up-to-date.

Bank receipts always have a date and time, that's _exactly_ the point I am making, the omission is part of the lie.

you are getting confused here.

what you have is a "paper receipt" (your checked out version) from your bank. something that, if you need an up-to-date version (from another remote), you need to request a new one (by issuing git fetch).

git is, by default, distributed, so whenever you need to see the world outside, you need to be explicit. linus made it this way because back in the day (not sure right now tbf) tons of kernel developers do work without any internet connection, and would only connect to pull/send patches.

this talk[0] by linus from 2007 (i remember watching it on google videos lol) explains really well where the git mentality came from. i really recommend it to you, since it feels like you are not really getting how git works.

[0]https://www.youtube.com/watch?v=4XpnKHJAok8

If you have a paper recipt (git status) it tells you when it was up to date, so you can determine whether you need a new one. Git doesn't provide that info. That's the problem, not that it can be outdated, but that it omits the date/time!

It’s a little offensive to tell another person that they are confused. If they are confused, they can say so.

Very good point. “Up to date with origin/master as of 4 hours ago” would be an improvement.

That is a lie though. Who knows if the remote has been updated? You wouldn't find out about that 4 hours until you did a fetch.

You can't go to the hotel desk clerk and ask if you have any messages. Then for the next four hours keep telling people "the front desk has no messages for me" despite you not asking them in the last 4 hours. Things could change!

No, this is exactly like a receipt from the ATM. “Your bank balance is $300.00 as of 10/10/23 10:10.” That was weeks ago, so I know to ignore it. The wording can likely be improved. Maybe “You are up to date with origin/master as last fetched 4 hours ago”.

> That was weeks ago, so I know to ignore it.

But you haven't talked to your bank, used an ATM, or been on the app in weeks! Your balance could be totally different - bills have came out, you got paid, interest, etc.

You are making my point! You know to ignore it because its old, outdated information.

Then why are you telling me this? How is it useful to me?

Of course youre up to date with what you last fetched - that is _always_ the case.

Why mention being up to date even? Just tell the user when they last synced with their remote(s).

You're making their point! `git status`tells you the status as of whenever you last fetched, and omits that timestamp. You can't tell if it's outdated, because it doesn't tell you when the last update was!

> Of course youre up to date with what you last fetched - that is _always_ the case.

But that is not what this message is about. It's confusingly worded, as many people agree, but what it says is that your local ref "main" points to the same commit as your local ref "origin/main." It says nothing about "main" on the other computer/server.

And it is not the case (i.e. you are not up to date with origin/main), for example, when you have committed to main but haven't pushed. It is also not the case when you have fetched but not merged.

> Of course youre up to date with what you last fetched - that is _always_ the case.

This might be where the misunderstanding is. You are not always up to date with what you last fetched. Say you have develop checked out, and you run a git pull. As part of that process, git checks the status of all upstream branches, and updates your local reference copy of them (that’s what origin/develop, origin/production, origin/feature-branch-1 are: your local reference copies of upstream). Then you check out production, which you last touched two weeks ago. Git will let you know that your two-week-old local copy is behind origin/production, which is your local reference copy of what it just saw when it fetched from upstream.

Git is a distributed system by design.

A problem it has is there is now a generation of developers who don't know why we don't use centralised VC any more.

Yes. Which is why temporal data and status is so important and makes things worse when left out.

Everyone uses git as a centralized vcs. You could remove the distributed part and 99% of people wouldn't notice. The killer feature was branches, which are orthogonal

Case in point. I take it you don't remember (or don't know) that truly centralised systems like Subversion required a network connection just to make a commit? The commit happened in the repository. There was no local clone. You could check stuff out. That was it.

Yeah, I've used subversion a bit. The DAG aspect and commits do not require a distributed system. I'm talking about the idea that git users would pull commits directly from other users and "build consensus" across the network, rather than push and pull from a central repo

Yes. I've never had a job in 20 years across 7 companies where I could code and not be on the corporate network. I am on a person device, remoting into a corporate network desktop, from which I am then ssh'ing into a linux box. Walking around with code on a local machine is practically a fireable offense.

For the vast majority of companies signing up for Github/Gitlab/whatever licenses, the remote/decentralized part of git is pointless.

So the decentralized aspects of git just add a layer of complexity/indirection for a lot of use cases. Many extra "git pull"s in my workday.

Yeah tbh I don't understand why you corporate guys use it either. I had a corporate job once. Hated it. They used git but, yeah, it could have been anything centralised. But for my purposes and I guess most people using git it's really important that it's decentralised.

I mean, we use whatever the boss tells us to, because that's how a job works?

git has a better experience than cvs or svn if you're far away from the VCS server, but that was solvable by having dev machines near the VCS server. I've gotten used to the git workflow, but it still doesn't strike me as uniformly better, other than if you're using git, you don't have to deal with everybody always ask why aren't you using git.

> Is it though?

Yes, yes it is.

origin/master is not saying that the remote has/hasn't changed. It's comparing your local copy of origin/master, not giving you the status about if remote has/hasn't changed. You need to explicitly ask if remote/origin/master has changed or not if you want to know.

Which in your analogy would be like if the store forgot to actually ask the bank if the customer had the money or not, and instead relying on whatever information they have "cached" in the store. Instead, the store has to first ask the bank (remote) if there is any changes.

I do agree that it could be worded better to actually help the user understand, as it seems to be a common misconception.

Sidenote: I'd be driven to absolute insanity if `git status` started doing remote requests to check the remote origin/master status each time I invoked it.

> You need to explicitly ask if remote/origin/master has changed or not if you want to know.

Git hurts my brain.

Seriously, what is the alternative? For `git status` to make a request to each of your remotes every time you run it?

> Consider a bank telling a store I am buying things at "This person has has €450 in their bank account", when at that moment I have €310.

That's pretty close to how holds / unresolved transactions work.

> It just refers to the last known commit pointed to by origin/master

The confusion lies in that origin refers to different things depending on if it's `origin master` or `origin/master`. Eg `git pull origin master` does the thing we expect

> The confusion lies in that origin refers to different things depending on if it's `origin master` or `origin/master`.

Git is not well designed for human beings.

It's sort of misleading because origin is not the origin, it's your copy of the origin. You have to fetch to make it the same. I can't suggest a better name, but you have to admit the word 'origin' suggests the origin, not some partial copy of it.

It's not a biggy, it's just one of the little toe-stubs and paper cuts you get over pretty quickly.

> origin/master is just a file on your system

Unless it's a packed ref (https://git-scm.com/docs/git-pack-refs), in which case it's just a line in the packed-refs file.

Reply on news.ycombinator.com