2

1 to 2 weeks ago, I found a reference on the web, saying that this command:

$ git  diff  origin  <branch>  HEAD

will show the present (local) commits that have not yet been pushed to remote. Since then, I have figured out that, as long as I am in the specified branch of interest, I do not need to specify the branch name on that command line.

I've been using that command, ever since, to help me perform some experiments, to help me learn how Git/GitLab work. Staying only in the development branch and doing no merges, I have repeatedly been able to:

  1. use that command to display not-yet-pushed commits; and then, after doing the "push"
  2. to run that command again and notice that all the previous commits, in the output of that command, were completely gone - i.e., the command gave no output.

But now I am experiencing some inconsistencies in the output of that command:

  1. I created a new branch, off of master, called jravery.
  2. I then created a new sub-branch, off of jravery, called jrasub.
  3. I added some files to jrasub; then staged & committed & pushed them.
  4. Then I merged jrasub into jravery; then I did a git push, in the jravery branch.

But now I do the git diff origin {branch} HEAD command and I still see those 2 files, whether the specified branch is jravery or jrasub.

Why were the committed-and-then-pushed files/commits disappearing from the output of that diff command last week, after push, but now still appearing in the output of that same command this week (also after push)?

Also in the output of that command - whether I specify master or jravery or jrasub as the branch - I am seeing a few other files that were never included in either the jravery or the jrasub branch. However, when I specify the development branch, nothing shows up in the output of that command, even though most of the files that are otherwise showing up in this command's output are - or were - only in the development branch (unless and until they might eventually have been merged into master) and never were part of either jravery or jrasub.

Why is that?

jonrsharpe
  • 115,751
  • 26
  • 228
  • 437
John Reed Avery
  • 121
  • 1
  • 7
  • 1
    If you are truly running `git diff origin`, it should throw a syntax error, as `origin` should not be in the working tree. It should be `git diff origin/`. Are you sure you don't have a local branch that's coincidentally *called* `origin`? – Obsidian Age Jan 24 '22 at 20:07
  • Interesting. The ONLY time that I get a syntax-error is when I am in a certain Branch AND also in a subdir to which that Branch has no access (or insufficient access, if that is such a thing). EVEN THEN, THOUGH: I *STILL* get the same output, but with the syntax command showing up after all the normal output. Isn't THAT strange!? But I'll try the different syntax you have mentioned. Thanks! – John Reed Avery Jan 24 '22 at 20:22
  • Hey, **Obsidian Age**. I tried your command-syntax and that seems to behave better. I need to do some more testing but I think that maybe you have pointed me in the right direction. Thanks again. – John Reed Avery Jan 24 '22 at 20:32
  • @JohnReedAvery, use @ mentions to get attention from a user, not bold type. Also, if you no longer seek solutions, please either provide and accept an answer or delete your question. – isherwood Jan 24 '22 at 22:25
  • 1
    I'll plug in `master` for `` here for concreteness: `git diff origin master HEAD` is a way of spelling `git diff origin master -- HEAD`. Unless you have a file named `HEAD`, you'll always get no output (or an error if `origin` and/or `master` don't resolve to something appropriate). – torek Jan 25 '22 at 01:35
  • @PeterJ: Hey. Sorry for breaking the rules. However, the best answer is what Obsidian Age wrote, above, and that is not listed as an official "Answer", which means that it does not have a Checkmark next to it, for me to click. So, what do I do in this type of situation? Do I create my own answer and simply copy-&-paste what Obsidian Age wrote? Thanks. – John Reed Avery Jan 25 '22 at 15:15
  • In a comment, you should ask obsidian age to convert their comment to an answer. Note that if you do not use correct @ mention syntax, obsidian age will not be able to hear you. – matt Jan 25 '22 at 17:17

1 Answers1

3

The problem is that git diff compares the first 2 arguments. The argument "origin" is just another commit, which in a normal bare repo likely just points to the default branch, or a syntax error if you don't have origin defined. Run this command to see what it is:

git log origin

For me in a repo that uses Git Flow, my top commit from that command yields the commit at: origin/develop, origin/HEAD.

So basically, this entire time you may not have been comparing what you thought you were comparing. If you change your command to:

git diff origin/<branch-name> HEAD

you'll probably get what you want. Interestingly, as your command was written, with the spaces between origin and your branch name, that means HEAD would be considered a third argument, which as torek points out in a comment, would be treated as a path instead of a commit. This would yield no output unless you have a file named HEAD.

Tip: there's an easier way to do this without having to type in the branch name at all:

git diff @{u} @

Basically, in this context, @ is short for HEAD, and @{u} is shorthand for your currently checked out branch's remote tracking branch (e.g. origin/my-branch-name). Since it's branch agnostic this'll work on any branch you currently have checked out, compared to it's remote tracking branch.

Side Note: git diff with two arguments is the same thing as using two dots to connect the arguments: git diff A B equals git diff A..B. But note if your branches have diverged you'll get both sides of the diff. If you only want one side, you can use 3 dots: git diff A...B. More info here.

TTT
  • 22,611
  • 8
  • 63
  • 69