Re: git: how to figure out with a script what the last commit on remote repo is without fetching it
Jonathan Dowland <jmtd@debian.org> writes:
> On Mon, Sep 08, 2014 at 11:58:35PM +0200, lee wrote:
>> One is using git:, the other one https:.
> snip
>> I don't have ssh access to any of the remote hosts. Both repos, I can
>> only clone/fetch/merge from.
>
> OK.
>
>> But I don't want to fetch? If I can fetch only the data (a minimal
>> amount of data) I need to figure out if the remote is more recent,
>> that's ok, though.
>
> I don't mean a full git fetch - I mean fetch only the information you need,
> i.e. what is the remote's head pointing at. If it's different, then there are
> likely more commits on the remote repository than local.
>
> With the HTTP(s) method, git fetches the following paths
>
>> http://somehost/somerepo/info/refs?service=git-upload-pack
>
> The server returns a string (as an application/octet-stream mime-type, most
> likely) containing something like the following
>
>> 1935f7966c0efffeb192824c53f30633b0030e74 refs/heads/master
I'm receiving 226542 bytes in 355 lines when I do this for one of the
repos ... and same for another one:
curl https://github.com/lee-/info/git-newer/refs?service=git-upload-pack | wc -cl
Perhaps this URL isn't right. To clone it, you'd use
https://github.com/lee-/git-newer.git. However, there are several repos
with https://github.com/lee-.
> You could write a script to fetch that file and compare that sha1 against
> your local repository, something like this (unfinished/untested)
One of the repos I like to be informed about is my upstream, meaning
that I may make commits to my local copy (fork) and push those to
another remote repo which is a copy of the local one. In case I make a
commit to my fork, the hash of my local repo will be different from the
hash of the remote one. You can also have several remote repos which
may flow into your local copy ...
Currently, my hash is 6f1cf... on the remote copy, upstream is
2db2c..., and my fork is 8cb83....
My fork is almost 160 commits ahead of upstream, but it's behind
upstream because with the last merge, a bug was introduced which I
haven't been able to fix yet. Hence I haven't pushed the merge yet.
So the script would have to remember what the hash was when the remote
repo was checked the last time. That's easy to do, yet I don't really
want to do it because it would require to create a file somewhere to
keep this information. OTOH, I might use a file anyway because it's
pointless that I get informed 20 times or so because I haven't fetched
the new commits yet.
>> # to be run from inside the local git repo
>> remoteurl=$(git config -l|grep remote.origin.url|cut -d= -f2-)
>> localsha1=$(cat .git/refs/heads/master)
>> remotesha1=$(curl "${remoteurl}/info/refs?service=git-upload-pack" \
>> 2>/dev/null | awk '/refs\/heads\/master$/ { print $1 }')
>> if [ "$remotesha1" != "$localsha1" ]; then
>> echo "the remote git repo has changed" \
>> | mail -s 'git repo has changed' you@example.com
>> fi
That's really good, it receives only 99 bytes :)
> In practice you would want to check all refs, not just refs/heads/master,
> to see if there any added (or deleted) branches from your local copy, and
> check the hash for each of them.
Hm, I think for my purposes it would be ok to only check master. I
might add this to my script and use some options so that either this
method can be used, or the output of 'git status' can be parsed.
> To persue this further, I'd suggest reading up on the git:// wire protocol
> (quite possibly there's a command other than 'git-upload-pack' which would
> give you what you want)
Talk directly to whatever serves the git: protocol? That'll be
interesting, I'll have to think about it :)
--
Knowledge is volatile and fluid. Software is power.
Reply to: