Your final edit is pretty important.
The fact that Git has a poorly implemented database for branch names and tag names and remote-tracking names and so on, combined with file name length limits on Windows, is what led to the problem. It's not related to git pull
at all, but rather to the way Git handles creation and update of remote-tracking names (refs/remotes/origin/TCCFOUR-19049-Algo-ProductionModul...
). So, what you want to do, temporarily, while the ridiculous branch name exists in the other repository and is causing these problems, is avoid asking your own Git to create this remote-tracking name.
The simplest method is to run git fetch
or git pull
with a refspec1 that limits the git fetch
action:
git fetch origin foobranch
for instance, if you want to update refs/remotes/origin/foobranch
. When that completes, you can run:
git merge origin/foobranch
or:
git rebase origin/foobranch
as appropriate. Should you wish to do both of these in rapid sequence without inspecting the git fetch
result first, you can use the convenience git pull
command:
git pull origin foobranch
which will run:
git fetch origin foobranch
(fetching just the one named branch and updating your corresponding origin/
name) followed by the git merge
or git rebase
that you have configured as your default second-command for git pull
.
1Refspec is a technical term. Here, it translates, rather roughly, as "branch name", but that's an enormous oversimplification. But let's not bother with the details here, and leave that for other answers.
Side notes
I generally prefer to run these as two separate commands, both for sanity—otherwise you're left wondering why one is foobranch
and one is origin/foobranch
—and for the ability to run other Git commands between the fetch
and the final command.
If you're still wondering why one is foobranch
and the other is origin/foobranch
, git fetch
itself is the reason: when you run git fetch origin
, you are telling your Git call up some other Git at the URL I stored under the name origin
. Your Git has their Git, which is connected to their Git repository, list out their branch names. They have their own branch names, because every Git repository has its own branch names. Your branch names are not their branch names. You and they share commits, but not branch names.
Anyway, once they have listed out all their branch names, your Git now has an opportunity to get the commits, so that you and they can share them. So your Git goes through the commits that are on their branches to see whether you have them already. (Remember that one commit can be on many branches, so even if they have a thousand new branches, you could have all of the commits already!) Your Git then obtains any new commits you'll need, first. Then, having gotten all the commits, your Git takes each of their branch names and creates or updates a corresponding remote-tracking name in your own repository. Your Git does this by sticking origin/
in front of each branch name.
When you run git fetch origin
, you're telling your Git: Get me all of their commits and branches. When you run git fetch origin foobranch
, you're telling your Git: Look at all their branches, but only get me updates for foobranch. So this limits your fetch to just those commits needed to update your origin/foobranch
.
Once the fetch is done and has quit, you'll refer to their latest commit using your name, origin/foobranch
, rather than their name, foobranch
. Should you wish to call one of your own branches foobranch
too, that's your business: they don't care what names you use. You probably do care what names you use, and use the same names they use on purpose. But that's not something they need to care about. That's something you do.