Git: Difficulty Getting Existing Git Repository to Track New Bare Remote Repository

Question

Summary: I'm having difficulty getting an existing local repository to track a new bare remote repository.

What I've tried: I've attempted to push my local repo to the new bare repo while setting upstream tracking. Git tells me upstream tracking is happening, but I still don't see the branch being tracked in the local repo's log, even after fetching the remote repo.

I've also tried creating a bare clone from the local repo, hoping this would work in a similar fashion to cloning another local repo where tracking is set up automatically, but I still don't see a sign of tracking in the local repo's log.

Request: Would anyone be able to take a look at the background information below, and guide me where I may be going wrong, or may have an incorrect understanding about how to get my existing repo to track the new bare remote repo? Thank you, I've tried my hardest to research this already.

Background I work as a manufacturing engineer in a small team. We would like to setup a workflow using a central shared remote Git repo for the team. I've been trying to setup a demo of how this would function, with the "centralRepo.git" directory below being our central repo, and having other folders team members can clone the central remote to.

Because we already have existing work, but no existing central remote repo, we will be starting with an existing repo in "davesClones" that will be pushed to the central remote, and then cloned to other team members folders as needed, such as "stevesClones."

What I'm expecting to see if tracking is working: If I clone a regular local repo, tracking is automatically setup and the log shows me my clones's own branches, along with the "origin" branch that it is tracking from the directory it was cloned from, as shown in the screenshot below circled in blue:

Attempt #1: Pushing w/--Set-Upstream:

I have tried pushing my existing local repo to the new central remote repo using git push --set-upstream <remote> master as shown below, and even though the output appears to say tracking was setup, I don't see any tracking happening in the git log like I did when cloning a regular repo, even after using fetch. Examples below show how I'm missing the origin tracking branch in log after trying the above steps:

Attempt #2: Clone -bare:

I also tried cloning the existing repo to a new bare repo, hoping this would automatically establish tracking, but as shown below the log doesn't appear to show any tracking happening, even after fetching:

Any idea why I'm not seeing tracking in my log? (Meaning how come after cloning a standard local repo I see a tracking [origin/master, origin head] but am unable to get this in my log when either using push --set-upstream to push local repo to remote, or when using git clone --bare to clone the local repo to a bare remote?)

Also the local repo does have a commit made in it, so it is not empty when pushing or cloning to the remote.

Thank you!

Answer 1

TL;DR

You need to start the whole process by setting up a remote in your own Git repository:

git remote add <name> <URL-or-path>

after which you must use the name part you used, instead of typing out the (presumably longer) URL-or-path. That is, you'll do:

git remote add origin /d/Seafile/...
git push --set-upstream origin master

Long

Let me start by saying that I really dislike the word tracking here as it misleads everyone. It has done that to you, too.

We must use git remote to create or otherwise manipulate remotes. A remote is just a short name—like origin, which is kind of the standard first-name-to-use for a remote—that will store a URL (and some other more-internal-to-Git information).

I am retyping from your screenshot, so I may introduce typos, but the key is here in this line:

git push --set-upstream /d/Seafile/Development/gitTest/centralRepo.git master

Let's take a quick detour through the Git documentation. The syntax for git push is described in the SYNOPSIS lines of the documentation as (abbreviated):

git push [options] [repository [refspec...]]

Here, your lone option is --set-upstream (which on its own is fine) and your repository is given as a pathname, /d/Seafile/.... If you jump down to the OPTIONS section, the repository parameter is described all too briefly like this:

<repository>
The "remote" repository that is destination of a push operation. This parameter can be either a URL ... or the name of a remote ....

What is unfortunately omitted here is that --set-upstream, and the kind of tracking that you want, only works if the parameter given is a remote.

A path name like /d/Seafile/...—which your Git internally translated to D:/Seafile/... as you can see in other output—counts as a URL rather than a "remote".

Remotes and remote-tracking names

Rather than saying that a branch name tracks some other name, I like to use the phrase has as an upstream. This phrase is unfortunately a bit awkward (hence Git's use of track as a verb). Any branch name can have either no upstream at all, or one upstream. When a branch does have an upstream, that can be either:

• another branch name, e.g., develop could have master as its upstream, or
• a remote-tracking name such as origin/master.

I call names like origin/master remote-tracking names (Git documentation mostly calls these remote-tracking branch names). They come into existence by stringing together the name of a remote, such as origin, with a branch name: the name of the branch in the Git that your Git converses-with, when your Git phones up the other Git using the URL stored under that "remote".

When you use git fetch or git push, you have your Git phone up another Git. There are two Gits; each Git has its own branches. Your Git has your branches, and their Git has theirs. Your Git offers to remember their names for you, as a service ... but for your Git to remember their branch names, your Git must come up with a name for each one that does not interfere with your own branch names. Your Git does that by pasting something in front of their branch names.¹

The part that gets pasted-in-front here is the remote name, e.g., origin. Without a remote—with a URL instead—there's nothing to paste-in-front, so the pasting-in-front never happens. The --set-upstream option becomes inoperative.

So why did your Git print:

Branch 'master' set up to track remote branch 'master' from 'D:/Seafile/Development/gitTest/centrapRepo.git'.

? The only possible answer here is that Git is very Gitty. It just said it did something that it physically can't do, and therefore didn't do.

---

¹Technically, remote-tracking names are in a separate namespace: branch names have fully-spelled-out names that start with refs/heads/, so that master is really refs/heads/master. Remote-tracking names start with refs/remotes/ and go on to include the name of the remote and another slash. The rest of the name is the stripped-down branch name as seen on that remote, at the URL. So their refs/heads/master becomes your refs/remotes/origin/master, which gets shown stripped-down to origin/master.