0

Consider a common scenario where we have two upstream branches set up for two local branches. This can be verified using git branch --all -vv which provides the following output:

* master                     74d2505 [origin/master] commit_message_X
  my_branch1                 55f5728 [origin/my_branch1] commit_message_Y

The corresponding remote-tracking branches are clearly shown above.

Now here is an experiment. I remove the line fetch = +refs/heads/*:refs/remotes/origin/* from .git/config and instead run git fetch origin +refs/heads/*:refs/remotes/origin/* directly in the command line. Then, I re-ran git branch --all -vv only to be surprised by the fact that all the remote-tracking branches within square brackets were gone:

* master                     74d2505 commit_message_X
  my_branch1                 55f5728 commit_message_Y

At the last part of the experiment, I added the line fetch = +refs/heads/*:refs/remotes/origin/* back to .git/config and ran an argument-less fetch git fetch origin. The remote-tracking branches got all back.

* master                     74d2505 [origin/master] commit_message_X
  my_branch1                 55f5728 [origin/my_branch1] commit_message_Y

Can anybody help me understand what is going on here? Why is it important to include fetch refspecs in the .git/config file and not in the command line? How does git exactly establish the remote-tracking branches shown within square brackets in the output of git branch --all -vv?

Just in case, here are some relevant parts of the .git/config file:

[branch "master"]
    remote = origin
    merge = refs/heads/master

[branch "my_branch1"]
    remote = origin
    merge = refs/heads/my_branch1
H D
  • 151
  • 6
  • What shell did you use to enter the `git fetch` command? What behavior does it have on non-match for glob items? (I'm guessing there were no files that matched `+refs/heads/*:refs/remotes/origin/*`.) Do you have `fetch.prune` set to `true`? What version of Git are you using? – torek Sep 28 '22 at 21:48
  • (I repeated this with an older version of Git, quoting the refspec, so I don't think there's any sh / bash match issues here. This seems like a bug in Git. It's probably version-dependent, but it may exist since 1.8.4 or something.) – torek Sep 28 '22 at 21:52
  • The thing that's happening internally is that the remote-tracking names go away (use `git branch -r` or `git for-each-ref` to observe this). I have fetch.prune set to true globally myself, which may be important. – torek Sep 28 '22 at 21:53
  • @torek Thank you for your responses. Just in case, I use `Git Bash` terminal on Windows 10. As you suggested, I ran `git branch -r` and `git for-each-ref`. I noticed all the remote-tracking branches (starting with `refs/remotes/origin/...`) are still listed. It is just that their _connection_ to the local branches disappears, at least as indicated by the output of `git branch --all -vv`. – H D Sep 28 '22 at 22:33

0 Answers0