4

I have a repository on github.com that I git pull down to my workstation, edit, commit then git push the changes back to github. This all works fine.

But I often clone read-only copies from github.com using e.g.:

git clone git://github.com/jhsrennie/Test.git Test-ro

Typically this is because I have temporary test installations that I won't be developing on, but I need to check the code builds and runs. The copy of my github repository can be read-only because no changes will ever need pushing back to github. The trouble is that when I pull down changes from github to my read-only copy using:

git pull origin master

I now find that git status shows something like:

$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#   (use "git push" to publish your local commits)

I can't push the changes back, and I wouldn't want to anyway, but the outstanding commits cause me problems e.g. I can't check out new remote branches. I end up having to delete my read-only repository and re-clone it every time I need to update it.

How can I update my read-only copies of my github repository from github.com without causing them to think there are commits I need to push?

Alternatively, am I doing this in a silly way and is there a better way to achieve my goal?

Response to Cupcake's answer

It seems strange to me as well, and there's clearly something I'm missing. This is how to reproduce the problem:

  • Clone the repository with: git clone git@github.com:jhsrennie/Test.git Test-rw
  • Clone the readonly copy with: git clone git://github.com/jhsrennie/Test.git Test-ro
  • Make changes to Test-rw, then git add and git commit

git status now shows (as you'd expect):

renniej@RATHAUS /d/Dev/GIT/Test-rw (master)
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.

And finally I push the change up to github with git push origin master

Now switch to the read-only copy and check that git status shows:

renniej@RATHAUS /d/Dev/GIT/Test-ro (master)
$ git status
# On branch master
nothing to commit, working directory clean

Update it using git pull origin master and I get (this was a change to the single file README.md):

renniej@RATHAUS /d/Dev/GIT/Test-ro (master)
$ git pull origin master
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.
From git://github.com/jhsrennie/Test
 * branch            master     -> FETCH_HEAD
Updating 76b02d1..5b03266
Fast-forward
 README.md | 2 ++
 1 file changed, 2 insertions(+)

and git status now gives:

renniej@RATHAUS /d/Dev/GIT/Test-ro (master)
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.

The only explanation I can think of is that the read-only copy doesn't recognise that the updates have come from the same repository that it was originally cloned from, but this seems strange to say the least.

John Rennie
  • 254
  • 2
  • 12
  • 2
    If git tells you there's one commit ahead of github's branch, and you didn't fetch from some other repo, then you *did* a commit on your read-only copy. How did it get there? – Pik' Aug 05 '13 at 17:20
  • 1
    Weird... on the Read-Only repo, could you run `git branch -a` and `git remote -v` and paste the results into your question? – Ajedi32 Aug 05 '13 at 18:47
  • Personally, I consider this another argument against using `git pull` in the first place. :-) But yes, Abe Voelker has the right answer, it's a mix-up where git doesn't realize who has which commits. – torek Aug 05 '13 at 21:09

2 Answers2

6

What's happening is the remote tracking branch origin/master is not being updated. If you read the git-pull man page, this is documented behavior for when git pull is called with arguments:

A parameter <ref> without a colon is equivalent to <ref>: when pulling/fetching, so it merges <ref> into the current branch without storing the remote branch anywhere locally

The simple fix is to make sure master is set to track origin/master, and then call git pull with no arguments, which updates the remote tracking branch for you.

If you've already ran git pull origin master and need to update the origin/master ref, then use git fetch or git remote update.

Community
  • 1
  • 1
Abe Voelker
  • 30,124
  • 14
  • 81
  • 98
0

As Pikrass points out, the message

$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#   (use "git push" to publish your local commits)

Is telling you that you have a local commit that doesn't exist in remote/master. Instead of deleting the entire repo and recloning, you can simply hard reset the local master to be at the same point as origin/master:

$ git reset --hard origin/master

From the information that you have given, however, it seems strange that your local master wouldn't already match origin/master if all you're doing is git pull origin master.

Also, instead of cloning new test repos from GitHub, if you already have a local copy of the test repo, you can simply make more clones of it locally, which will be faster since it doesn't have to download the repo over the network:

$ git clone <directory path to local repo> <new clone name>

However, without additional configuration, this new clone will have the local repo it was cloned from set up as origin, so it won't be read-only, and will be possible to override changes in original clone if you push from the new clone.

Community
  • 1
  • 1
  • Thanks, but I'm **definitely** not changing anything in the RO copy. I've edited my question to show exactly what I did and how to reproduce the problem. Cloning locally isn't possible because I'm checking Win32 code builds on Linux and OSX and the line breaks are different. Cloning from github corrects the line breaks on the fly. Using git reset --hard origin/master just discards the changes I've pulled from github. This makes me wonder if the RO repository is confused about its origin. – John Rennie Aug 05 '13 at 18:21
  • @JohnRennie do you know that you can control the line breaks in your checkout using either the `core.autocrlf` setting or a `.gitattributes` file? It's not "cloning from GitHub" that "corrects the line breaks", it's the act of checking out your working copy with these settings that does it. You can have local repos cloned from other local repos that do the same thing, you just `git init` them, make the settings changes, then add remotes and `fetch` and `checkout`, which is basically what `clone` does. –  Aug 05 '13 at 19:00