Do I need to 'fetch' before checking what the current SHA on a Git remote is?

Question

I (think) I understand that I can use git rev-parse to determine the SHA of the current commit on any of my local Git branches, including those that begin with remotes/...; but I gather that this will not reflect the state at remote repositories corresponding to the latter unless I first git fetch. Is that correct? Is

git fetch origin master
git rev-parse remotes/origin/master

the correct idiom for determining the SHA of the current commit on a remote branch? Are there side effects to performing the fetch that make this overdone? Is there another way?

Answer 1

You are correct. Unlike tools like SVN, Git only stores and uses information locally.

If you want to see the very latest activity that may have been performed on a remote repo you can either:

1. git fetch
2. Remotely browse the repo, if the owner has enabled it.

Running git fetch regularly may not be a problem depending on you network etc. However, even with SVN, most people don't care about other commits until they themselves are ready to commit so having your repo updated every 60s is probably overkill.

Git users often commit and push their feature branch and so also don't care about other branches until integration time, which might be later and done in a different repo.

You need to make a choice that makes sense for your workflow and setup. However if you are migrating from a centralised model (such as SVN) don't be afraid to let go and try something more "Git'sh" for a time :-)

With regard to remote browsing. Git comes with a subcommand called instaweb git instaweb --help that will be able to serve repo info via browser

Answer 2

git ls-remote origin master would also give you the sha of origin/master without actually performing a fetch (it won't download any objects or update anything in refs/remotes) but it's not part of any ordinary git workflow, probably because a sha isn't very useful without the commit that it refers to.