[civopsec]

See also:

- The git staging area, the term literally everyone agrees with

- https://news.ycombinator.com/item?id=28143078

> “Your branch is up to date with ‘origin/main’”

> ... But it’s actually a little misleading. You might think that this means that your main branch is up to date. It doesn’t.

No need to well-actually this one. Isn’t the Two Generals problem applicable here? If you are being really pedantic, it is impossible to tell whether you are “up to date” right this split second. Even if you do a fetch before `status`. So what’s the reasonable expectation? That the ref in your object database—on your own computer—is up-to-date with some other way-over-there ref in an object database last time you checked.

A simple `status` invocation can’t (1) do a network fetch (annoying) and (2) remind you about the fundamentals of the tool that you are working with. In my opinion. But amazingly there are a ton of [votes on] comments on a StackOverflow answer[1] that suggest that those two are exactly what is needed.

> I think git could theoretically give you a more accurate message like “is up to date with the origin’s main as of your last fetch 5 days ago”

But this is more reasonable since it just reminds you how long ago it was that you fetched.

[1] https://stackoverflow.com/questions/27828404/why-does-git-st...

...

Another thing: I thought that `ORIG_HEAD` was related to `FETCH_HEAD`, i.e. something to do with “head of origin”. But no. That “pseudoref” has something to do with being a save-point before you do a more involved rewrite like a rebase. Which was implemented before we got the reflog. I guess it means “original head”?

[happytoexplain]

I'm pretty pro-Git, but I agree with the author on the wording of that message (though I disagree with their suggested alternative). "Your branch is up to date with ‘origin/main’" is technically correct, but the usage of the phrase "up to date" implies on a casual reading two things: That main matches origin/main, and that origin/main is up to date (i.e. that it was updated as part of the command, or is being kept up to date automatically and the last successful sync was arbitrarily recently). We're talking about a user-facing status message, not a machine-readable signal that must be true during this CPU cycle. This is a reasonable interpretation without having to get into networking theory.

"Up to date" means caught up in time, as opposed to space. Local branch positions are more like space ("where is this branch pointing?") and remote ref state is more like time ("when did I last update the remote ref?"). I know, that's very subjective. Either can mean either.

Anyway, I think a better wording might be "Your branch matches origin/main" or "Your branch's head is the same as origin/main" or "Your branch is pointing to the same commit as origin/main" or some other tradeoff between verbosity and clarity. Maybe with the author's suggestion as a parenthetical: "Your branch ... origin/main (remote ref last updated 5 days ago)."

[Lutger]

I like the last one and would shorter it to:

"Your branch ... origin/main, updated 5 days ago."

[civopsec]

> Anyway, I think a better wording might be "Your branch matches origin/main"

That’s fine. And also less partial to the implicit view that the remote ref is the thing you are supposed to be “up to date” with.

[fernandotakai]

>A simple `status` invocation can’t (1) do a network fetch (annoying)

i don't think that's annoying. i want network operations to be explicit, not implicit. when i do git status, i wanna know the status of my repository as is in my file system.

if i want to know what's going on in another remote, i will fetch that and then compare.

[dooglius]

The expectation is that the information you get is up-to-date as of the time you started the status command, yes there can be a race in the time it takes to present information to your terminal but that's a small time window. This more or less means you want to fetch, yes. Two Generals problem is only applicable on the remote side, which may keep sending retransmits for a while, if it doesn't get acks that you received its data (which isn't the client's problem). If the client doesn't get data from the server presumably the right behavior (which I'd expect happens now with fetch) is to hang and print an error after a timeout.

[civopsec]

> The expectation is that the information you get is up-to-date as of the time you started the status command,

Why is that the expectation of a “distributed VCS”?

[fragmede]

That's your expectation, but how does that work without Internet access? You're holding it wrong...