10

From a git branch, a colleague of mine ran 

git diff origin master

What is it supposed supposed to do? What does origin separately point to?

This is related, but not covered in In Git, what is the difference between origin/master vs origin master?

Community
  • 1
  • 1
Senthil Kumaran
  • 54,681
  • 14
  • 94
  • 131

5 Answers5

6

This form of git diff just takes two revision specifiers, as described in gitrevisions.

In this case origin is most likely to match item 6:

  1. otherwise, refs/remotes/<refname>/HEAD if it exists.

So this means the same as git diff origin/HEAD master: resolve origin/HEAD to a commit-ID, resolve master to a commit-ID, and diff the two commits.

Run:

git rev-parse origin

to see how the resolution works.

zenpoy
  • 19,490
  • 9
  • 60
  • 87
torek
  • 448,244
  • 59
  • 642
  • 775
  • Is `fetch` mandatory before this command ? or does it goes already to the remote repository and checks.... ? – Royi Namir Mar 01 '19 at 11:07
  • @RoyiNamir: It's not *required* that you run `git fetch` first, but if you don't, your Git is using the information saved from the *last* fetch (or perhaps updated by a previous `git push`). If you think new commits may have appeared on the remote since the last time your Git had a conversation with the remote, and you want to see those commits, run `git fetch` now to get your Git to talk to theirs now. Then, any time, use `origin/` to refer to the information saved by this latest `git fetch`. – torek Mar 01 '19 at 16:18
  • In other words , what is the fastest way to check if there is a new version in the remote side? A fetch must be made then.... right? – Royi Namir Mar 01 '19 at 16:24
  • @RoyiNamir: yes, you must contact the other Git, and `git fetch` is probably the simplest and easiest way to do so. You can use `git ls-remote` to do just the first step of fetch (obtain names and hash IDs) but if they *do* have new commits, you probably want the new commits anyway. Note that by the time you get an answer from them, your answer may be out of date: for instance, suppose it takes 2 seconds for packets to reach your machine, so you fetch and they say their `master` is a123456. That information is at least two seconds old: someone might have done a push one second ago! – torek Mar 01 '19 at 16:27
  • The upshot of all of this is that It's sensible to do a `git fetch` first, but don't count on your information being up to date, no matter how recently you obtained it, unless you have a larger surrounding protocol. That's a fundamental problem in any distributed system: information you have, locally, may not match information they (whoever they are), have locally-to-them. You must build atomicity some other way, e.g., using compare-and-swap requests ("I think you think A=3, if so set A=4, and in any case, let me know what you did") or leases ("tell me A and don't change it for 30 seconds"). – torek Mar 01 '19 at 16:30
  • Thanks for the extra info. Btw i never understood where in the 3 trees (working folder,index,repo) does fetch file are being downloaded to , if they aren't merged – Royi Namir Mar 01 '19 at 16:32
  • `git fetch` doesn't download *files*. It obtains *objects* (typically commits+trees+blobs) and their hash IDs, and adds those objects to your repository. Your repository isn't a tree, though. It's bigger than a tree: it has one big database of all Git objects (of four types) which forms a directed acyclic graph, a smaller database that maps from names (branch names, tag names, and other references) to hash IDs, and some ancillary data. (Meanwhile your work-tree *is* a tree, and your index is a sort of flattened-out tree.) – torek Mar 01 '19 at 16:37
3

"origin" points to the "remote", typically where you cloned the repository from, see 

$ git remote -v show

But specifically in answer to your question "git diff origin master" is equiv. to this: 

$ git diff origin/HEAD master

origin/HEAD to the branch pointed to by HEAD reference on the remote. Which was the checked out branch at last pull.

Take a look at your commit graph, which will show you where all your references are (--decorate)

$ git log --oneline --graph --all --decorate
Amos Folarin
  • 2,059
  • 20
  • 18
2

It is equivalent to

git diff origin/HEAD master
Jan Hudec
  • 73,652
  • 13
  • 125
  • 172
2

It shows the changes between the tips of origin/HEAD and the master branches. You can achieve the same with following commands:

  • git diff origin/HEAD master
  • git diff origin/HEAD..master

Usually origin points to the source from where you cloned your repository.

David
  • 2,987
  • 1
  • 29
  • 35
1

It depends... if origin and master are branches, it shows the difference between them. When looking over explanations, they usually use origin to stand for the original (upstream, official, whatever) branch, and master for the branch you are working on. I.e., "show me what changed with respect to the original version."

vonbrand
  • 11,412
  • 8
  • 32
  • 52