CODEWITHSUNDEEP
git
John Rennie
John Rennie

Reputation: 282

Keeping multiple read-only copies of a git repository

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:

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.

Upvotes: 4

Views: 2204

Answers (2)

Abe Voelker
Abe Voelker

Reputation: 31574

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.

Upvotes: 6

user456814
user456814

Reputation:

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.

Upvotes: 0

Related Questions