how to check remote git repo for updates without pull/fetch

Hello. I have not very hard question, but I don't know how to better do it - could you tell me, please, does exist some way to check remote git repository for updates without downloading any essential files? I suppose, that such command should just type something like: "already updated", if current working tree identical to remote repo, and something like "there is some updates in remote repo", if remote repo has some new commits and/or branches. Thanks.

Ivan Zorin <ivan.a.zorin@gmail.com> wrote:

There aren't any commands to do it.

What you could do is write a script based upon git ls-remote. A really simple one might be:

	#!/bin/sh
	remote=$1
	o=.git/remote_cache.$remote
	n=$o.new$$
	git ls-remote $remote >$n
	if [ -f $o ]
	then
		if diff $o $n >/dev/null
		then
			echo "No changes"
		else
			mv $n $o
			echo "Updates available"
	else
		mv $n $o
		echo "New remote remembered..."
	fi

A much more complex one would actually rewrite refs/heads/ to the correct refs/remotes/ namespace on your local repository and compare the remote ref values to the local refs/remotes values.

Patches for git fetch --pretend or something might be interesting. Though I recall a thread about this before on the MLand saying there was no point. Its not like you can see how big the download would be until after its over.

Well, actually, I think, that I've found one of possible soulution already: First, check remote repo: $ git ls-remote /path/to/git/repo <some sha1-hash> HEAD ... Then check local repo: $ cat .git/HEAD ref: refs/heads/master $ cat .git/refs/heads/master <other sha1-hash> So, if both hashes identical, then current working tree with HEAD, which points to "master", already up-to-dated, but if they don't, then there is some updates at remote repo.

Here is the script I use:

#!/bin/bash # # does this git repo need a pull? # l=$(git log|head -1|awk '{print $NF}') r=$(git ls-remote origin heads/master|awk '{print $1}') test "${r}" != "${l}"

-JimC 

2008/12/20 James Cloos <cloos@jhcloos.com>:

Hello

Your script will report false positives if you run that in a branch where you've made local commits since git log's output will list a commit that's not on the remote side. Thus it'lll say 'you need to pull' when really what happened was that you committed locally and the sha1 test is no longer equal. This is one of the reasons why it's a good idea to always keep your local master clean.

There's two things you can do:

1. assume that you always keep your local 'master' branch clean.
That'll let you quickly compare your local master versus origin's
master:

#!/bin/sh remotemaster=$(git ls-remote origin heads/master | awk '{print $1}') localmaster=$(git rev-parse master) test "$remotemaster" = "$localmaster"

2. You might have a local branch that's not called master but is
tracking origin/master.  Or, your master branch might not be clean.
You can accomodate that workflow with:

#!/bin/sh remotemaster=$(git ls-remote origin heads/master | awk '{print $1}') branchpoint=$(git merge-base origin/master HEAD) test "$remotemaster" = "$branchpoint"

The difference is that we're checking against the branch point. If origin/master is beyond the branch point then chances are you need to pull.

---- off topic, but related ----

BTW one sound recommendation that I've heard on this list is that your topic branches should really be free of any unrelated changes. Pulling stuff in "just because" changes the branch. It's no longer just "topic" -- it's now "topic" + whatever they happened to push upstream. That has some implications in that it makes it harder to review what exactly went into the specific topic/feature since the branch's history now contains unrelated changes.

An advantage of keeping your topic branches clean is that you can run:

    git diff $(git merge-base HEAD origin/master)

in your topic branch and you'll see *only* the changes that went into that branch. If you get into the habit of pulling stuff in then you'll see your changes *and* stuff you've pulled in, which probably has nothing to do with the original topic/feature, etc. etc.

Anyways, this is an entirely different topic/conversation and might not apply to your specific circumstance but I figured I'd mention it nonetheless.

On Saturday 2008 December 20 17:41:13 David Aguilar wrote:

Change the last line to: test "${r}" != "$(git merge-base "${r}" "${l}")" and those false positives should go away.

The script is far from a complete solution to the OPs problem though. It only checks one, specific remote branch. It only checks against the current branch. It is the core of something that might be useful as another subcommand to 'git remote' though.

David> Your script will report false positives if you run that in a branch David> where you've made local commits since git log's output will list a David> commit that's not on the remote side.

Ah.  Yes.  I forgot to mention that.  Good catch.

I wrote the script specifically for use with the repos created by Gentoo's git eclass (used when installing packages from git repos rather than from tars or the like). As such, it only needed to deal with pristine clones.

-JimC