CODEWITHSUNDEEP
gitgithub
ManUtdBloke
ManUtdBloke

Reputation: 453

Github release/tag not showing up locally?

I pushed some code to a remote repository and then created a first release on GitHub, giving it the title 'v0.0.1'. GitHub now shows that I now have one release and also shows that in 'tags' I have a tag 'v0.0.1'.

I then executed git pull origin master to update the local repo and it returned 'Already up-to-date.' Now if I enter git tag nothing happens.

So why isn't this tag showing up locally?

Upvotes: 3

Views: 3271

Answers (1)

torek
torek

Reputation: 488103

The problem here is that git pull origin master runs git fetch origin master followed, in effect, by git merge origin/master. The git fetch step provides too many constraints on git fetch, inhibiting it from obtaining your tag. If you yourself run git fetch origin or even just git fetch, you will obtain the tag.

Background

Note that the first command that git pull runs—git fetch origin master—uses two separate arguments, origin and master, and the second does not; instead, it has this odd slash: git merge origin/master. This is all due to history: git pull was there first, back in 2005 or so, and it turns out to do too much and to do it not so well; so a separate, more-useful git fetch was provided as a standard user-facing command. Around this time, the whole concept of "remotes" was invented. The name origin is itself one of these remotes.

Remotes come with remote-tracking branches, and origin/master, with the slash in it, is one of these remote-tracking branches. Despite the word "remote" here, a "remote-tracking branch" is in fact just another name in your own (local) repository: it's your Git's way of remembering for you what your Git saw on the other (origin) Git, the last time your Git talked to theirs.

In the beginning (2005-ish again), you had to run git pull <url> <branch>, which is why the two are separate. There were no remotes, and no remote-tracking branches, so you had to have your Git call up their Git by URL, obtain their branch, and then immediately merge the result into your branch. So you named the URL by which to call up their Git over the Internet-phone, and then named their branch.

You can now run git fetch with no arguments at all, which will call up origin (your Git uses your name origin to save the URL) on the Internet-phone and obtain everything, and then remember it all for you, using tags and remote-tracking branches. After that, git merge with no arguments at all will generally do the right thing: if you're on master it will merge origin/master, which is what your Git remembers from their Git. But git pull lives on, in part because after git fetch, you usually want to do at least one more Git command, and git pull does git fetch and then one more Git command—and it still uses that same old syntax: a URL (but now you can use a "remote" name), followed by the name of the branch as seen on the Git at that URL.

My advice to those new to Git is: never use git pull; your Git life will be happier. It seems convenient, but it has all these traps for the unwary. For instance, the second command you run should quite often be git rebase, not git merge. The way to find out which command to use is to run git fetch and then git log—but git pull requires that you decide in advance whether to rebase or merge, before you look to see which would be better.

Upvotes: 3

Related Questions