Here is what I have done.

1. I have made a new commit in GitHub
2. Did "git fetch" in my local machine

Expectation:

Tracking branches would be updated, but local branches would remain as is.

What I observed:

As per what I read online, git tracking-branches are stored in "packed-refs" file in .git folder. They are still pointing to the old commits.

Please note that the fetch operation is successful.

My question : Why are the tracking branches in "packed-refs" not updated?

CodePudding user response：

There's no guarantee when or if references are stored unpacked or packed, or if some future version of Git will store them in some third way (e.g., a real database). You should generally not look at the files inside the .git directory (except to satisfy curiosity), but rather use the provided APIs (e.g., git rev-parse).

The more interesting question is whether, when the remote repository acquires updated branches, the git fetch prints out updates:

$ git fetch
[various messages ending with the "From <url>" part, snipped]
   dc8c8deaa6..e4a4b31577  maint      -> origin/maint
   69fb817120..8ac04bfd24  next       -> origin/next
   a5b07a7eda...3df86c6a86 seen       -> origin/seen  (forced update)

If these updates are not getting printed, git fetch did not update anything. In that case, the next interesting thing is what remote.origin.fetch is set to, assuming the name of the remote is origin:

$ git config --get remote.origin.fetch
 refs/heads/*:refs/remotes/origin/*

If your remote.origin.fetch (or remote.remote.fetch) line is different, what does it contain and why?

CodePudding user response：

@toreks's advice is good: use and trust the git commands unless you've got concrete, articulable reasons not to. "I'm curious how it currently works" works for me, though, so: Git checks individual files before looking in packed-refs. That way looking up any single ref doesn't have to deal with 7420 packed refs just to find the one tracking branch you're after.