Julia Evanspoll: when you see this message in `git status`:
”Your branch is up to date with 'origin/main’.”
do you know that your branch may not actually be up to date with the `main` branch on the remote?
yes
mostly yes
no
what?
Poll ended at .
dazraf(i've been wondering if there's a world where it's possible to convince the folks who make git to change that message to add “... as of 5 minutes/3 days/6 years ago”, but I think it might be hard to implement)
cliffle@b0rk That would be fantastic.
iliazeus@b0rk just a "(last commit at ...)" addition after this message would even suffice, I think
mxey@b0rk hmm the ref files should have an mtime that can be used for that, shouldn’t be so hard
Brian Campbell
Ben Zanin
Robert Thau@rst @unlambda @mxey @b0rk yes, agreed, it should be simple conceptually and implementation-wise to meet the need; I was just making the point that an implementation _is_ needed, since the required information is not already present in the existing data structures.
Hmm, I _think_ a proc-receive hook¹ could potentially offer a prototype implementation with no core changes but to be honest that documentation is a little obtuse. I'll have to read the code some more.
Dominik Janiec@b0rk sound great! Why it could be hard?
emily dogmom@b0rk it COULD be? i think we can get it easily from mtime of .git/refs/remotes/<tracking remote>/<tracking branch>
@b0rk you can totally propose it to git at vger dot kernel dot org if you want, or i think you're already in the git discord, we'd be happy to advise through implementing a patch ;) ;)
@b0rk but i just tried out examining the mtime on .git/refs/origin/master before and after a fetch on my almost-always-stale laptop clone and it totally looked right
malte@nasamuffin @b0rk i voted "no" because i always forget, so i would be really stoked about this 🥺
@nasamuffin ooh i didn’t know there was a git discord!
@nasamuffin the edge case i was worried about is that it looks like it doesn't update the mtime if you push (or fetch) and there were no updates?
(which makes sense because it wasn't modified, but the thing I _want_ is to know “we know that this is up to date as of X time” not “this is the last time there were new changes”)
@nasamuffin anyway I'll join the discord!
@b0rk sure, welcome! it's pretty new (~1yr) but more active than we expected it to be, for a bunch of crusty foss C devs
@b0rk yeah i saw that too unfortunately. that's pretty tricky, but we might be able to nudge the mtime on that ref anyway when we attempt the fetch and nothing happens 🤔
Olivier Mengué@b0rk @nasamuffin mtime is not much reliable anyway. Some filesystems do not record it or are specifically configured to not record it.
For example to optimize caching of Docker image layers mtime gets in the way (I don't remember the implementation details)
For example to optimize caching of Docker image layers mtime gets in the way (I don't remember the implementation details)
Zalasur 🐸🇺🇦@b0rk I think just adding the prepositional phrase "on local" at the end of that message might be enough to save us a bunch of headaches just by itself.
Tommi Komulainen@b0rk I'd guess it'd be approximately trivial. either check the timestamp of some file git already creates, or if that's not trustworthy enough add an explicit timestamp of last fetch somewhere 🤷
FXBOY4EVA@b0rk and not just for the reason you think.
Hugo Slabbert ⚠️@b0rk I feel like the fundamental issue could quite possibly be the folks who control git development thinking the line is perfectly accurate ("you see, origin/main represents your LOCAL view of that tree. It's entirely different from the remote lol!") rather than recognizing it is thoroughly confusing from a user perspective. So, like, literalism that requires everyone seeing that line interpreting the concepts the same way as git developers do, rather than recognizing the most obvious or straightforward interpretation of the message.
Ben Ramsey@b0rk They could store the last time you fetched from each remote in .git somewhere.
@b0rk It shouldn't bee too difficult to implement; the reflog already contains that information:
~/src/git$ git status
On branch main
Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean
~/src/git$ git reflog --date=relative origin/main
f5aaf72f1b (HEAD -> main, origin/master, origin/main, origin/HEAD) refs/remotes/origin/main@{1 year, 10 months ago}: fetch: fast-forward
0f828332d5 (master) refs/remotes/origin/main@{1 year, 10 months ago}: fetch: fast-forward
@unlambda yeah of course. The problem is it doesn't update the time if you fetched and pulled but there were no new changes
Nick has moved to Mathstodon@b0rk It seems like being opaque is sort of a git design principle. Like I could imagine someone creating a git fork that's just "git but make the messages and nomenclature not comically misleading." I guess in the meantime we'll have to settle for the illuminating things you post. 😀
Jakub Narębski@jnareb It seems like (b) is true of a lot of software and (c) is true of virtually all software, so it still doesn't seem to explain why git has such exceptionally opaque semantics. I would assume that they don't do user testing, but again that doesn't seem exceptional among software projects.
@b0rk
@b0rk
Graydon@b0rk the general case slams into the possibility of multiple remotes. (I mean, I'm a cabbage and my personal repository has multiple remotes, that's how I back it up.)
"Nothing's different that we know about. Ask a remote?" or similar might be a better message anyway.
@unlambda @b0rk Dim recollection says you don't get that specific remote tracking branch message when you didn't clone the repo/don't have a default remote.
In that specific extremely common case, sure, you could ask the reflog. But I wouldn't want to try to talk the git maintainers into considering that a general solution.
Peter Bindels@b0rk Should be easy? Compare to filedate of ref, touch ref if you pull/fetch and it doesn't change.
Michael Sokolov@b0rk or maybe " up to date with your latest fetched copy of..."
robryk@b0rk Especially that you can manually manipulate the remote ref, and then there's no way of telling what that means.
Nick Radcliffe has moved@b0rk This confused me for years. Even though it’s correct in git’s world, it seems hostile.
I don’t love the time idea because it perpetuates the misleading idea that it’s checking. It’s really just talking about to sets of files on one machine, so I feel as if ‘up to date with your local copy of’ or ‘’the last fetch of’ would help me more.
Mark Dominus@b0rk Seems to me that it might not be hard. There's already a per-branch database in `.git/config` where last-fetched times could be recorded.
Ricardo Signes 
Thomas Sibley@rjbs @mjd @b0rk Here's an incomplete but working patch. https://gist.github.com/tsibley/81d144149812b009e833b9b1a667c2b9
I've thought about this a bit before and have been meaning to look into it for a while... so I got nerdsniped this afternoon. Might try to see this thru to patch submission.
@rjbs @mjd @b0rk Oh bah, I see I totally misunderstood and missed this edge case: https://social.jvns.ca/@b0rk/112061735287996245
orz
Apologies.
Julia Evans (@[email protected])
Attached: 1 image @[email protected] the edge case i was worried about is that it looks like it doesn't update the mtime if you push (or fetch) and there were no updates? (which makes sense because it wasn't modified, but the thing I _want_ is to know “we know that this is up to date as of X time” not “this is the last time there were new changes”)
@rjbs @mjd @b0rk Extended the patch to solve that by recording all fetches in the reflog. https://gist.github.com/tsibley/0eb1f9d227b143fb7fe97fc2661eac9a
Not sure that'd fly with the git maintainers or not... but I might try to engage and see!
@b0rk I'm not sure if it would be possible without adding something extra.
Git can always check the committer date of the last commit on remote-tracking branch, but it this would not change when you refresh and remote does not have any changes.
With remote-tracking branch stored as loose ref (a file), you can check the modification time... but not if it is turned into packed ref, or if in the future Git would start using reftables backend for storing branches and remote-tracking branches.
@b0rk or to be more exact: modification time of loose ref would not change (as other already wrote) if the ref didn't change, and if it did not change for long time, it could be repacked into packed-ref format (and loose even this bit of information).
The reflog could record every fetch, successful or not, but I am not sure if it would not have some complications in other parts of git.
Norman Wilson@b0rk `when I last looked'
Jean Helou ⌨️@b0rk That would be great for "centralized" remote where you have write access (day to day work).
it could be much less relevant in more distributed contexts where the reference of origin/main (the main of your fork on GitHub for instance) is not necessarily up to date with upstream/master Which is what you would like to target for your PR for instance. In such a case it could actually be misleading.
it could be much less relevant in more distributed contexts where the reference of origin/main (the main of your fork on GitHub for instance) is not necessarily up to date with upstream/master Which is what you would like to target for your PR for instance. In such a case it could actually be misleading.
testerab@b0rk
"as of the last time updates were fetched" or "as of the last sync" might work almost as well to help people understand what's actually going on under the surface of that message?
"as of the last time updates were fetched" or "as of the last sync" might work almost as well to help people understand what's actually going on under the surface of that message?