7

I used Bitbucket to compare two branches. When I compared my master branch (as my source) to my uat branch (as my destination) and looked at the diff, I noticed that the list of files are totally different when I compared uat (as my source) to master (as my destination). There are a lot more files that are different when comparing master as my source. Whereas, there are only a few files that are different when comparing uat as my source. Why would the order of which I compare differ? Why would the source and destination even matter when comparing two branches?

Also, I noticed that most of the files that are listed in the diff have identical content but the only difference is the commit hash.

Here are some screenshots. I am using the BitBucket UI to compare the two branches. When letting master be my source you can see the settings folder being included in my screenshot which isn't there when I let uat1 be my source.

uat1 as my source

master as my source

Improve this question
11
  • What actual commands are you running? Also, what do you mean "files that are different have identical content but the only difference is the commit hash?" Individual files don't have a "commit hash". They do have their own object ID (hash), but if the content matches then so will the hash (and, practically speaking, vice versa) Commented Mar 6, 2018 at 16:35
  • btw, what I think is happening is, if you're checking out master and doing git diff uat, then checking out uat and doing git diff master, and somewhere between master and uat someone changed the line ending sequence, then depending on your autocrlf settings, what you have in the work tree could differ in one case but not the other. And this would make the files "look" the same while still calculating different hashes. Commented Mar 6, 2018 at 16:37
  • @MarkAdelsberger I noticed this behavior when I was merging. I did a basic merge command git merge master and then when I fixed all the conflicts and looked at my git status I saw a bunch of files that were going to get committed. However, I knew the only changes I made in the uat1 branch were a few files so I compared the two branches in bitbucket and noticed the list of files of the diff were totally different when chosing what source and destination to compare the two. Commented Mar 6, 2018 at 16:39
  • When I had uat1 as my source and compared it to master I noticed the correct list of files of changes. But when I had master as my source and compared it to uat1 , the list of files in the diff were around 50. And then I compared some of the files from uat1 and master that were in that list of 50 and noticed that they are identical and the only difference was the hash commit. Commented Mar 6, 2018 at 16:41
  • @MarkAdelsberger Hmm, I see. That is so strange. Commented Mar 6, 2018 at 16:42

2 Answers 2

Reset to default
7
+25

TL;DR

On your local repo, you need to look at the following diff:

# the diff: git diff master...onemsg-uat1 # 3 dots, not a typo git diff destination...source # the list of modified files: git diff --name-only master...onemsg-uat1

more details below

The screen capture you show has a notion of source and destination branches, and has a Create pull request button.

I'm not familiar with Bitbucket GUI, but all git services that offer a Pull Request mechanism (Github, Gitlab (they're called "Merge Requests" in Gitlab), Azure Devops, ...) have a similar view :

the diff that is displayed is :

  • the list of changes that source would bring in if you merged it into destination

which is not the same as :

  • all differences between source and destination.

With a diagram :

# say your branches 'master' and 'release/onemsg-uat1' look like this : D--E--F <- release/onemsg-uat1 (source) / --*--X--A--B <- master (destination) ^ fork point, aka "merge base"

To represent "the changes brought in by the source branch", rather than looking at the complete diff between B and F, the GUI presents you with changes starting from X :

a. if you open a Pull request to merge release/onemsg-uat1 (source) into master (destination) : the changes to review are the diff between X and F,
b. if you swap the branches, and look at what master would bring to release/onemsg-uat1 : the changes to review are the diff between X and B.

In git terminology, X is called the "merge base" of the two branches, and you can get its sha1 with git merge-base master release/onemsg-uat1.

One first way to look at those diffs from your local repo is :

# changes introduced in release/onemsg-uat1 : git diff $(git merge-base master release/onemsg-uat1) release/onemsg-uat1 # changes introduced in master : git diff $(git merge-base master release/onemsg-uat1) master

There is a shortcut for the above command : the three dots notation git diff a...b

# changes introduced in release/onemsg-uat1 : git diff master...release/onemsg-uat1 # changes introduced in master : git diff release/onemsg-uat1...master

To list only the affected files, use --name-only or --name-status :

git diff --name-only master...release/onemsg-uat1 git diff --name-status master...release/onemsg-uat1

To open this diff in a graphical diff viewer, use git difftool :

# the following command will open the differing files one at a time : git difftool master...release/onemsg-uat1 # with the '-d' option, you will view the diff of two complete directories : git difftool -d master...release/onemsg-uat1
Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

3

Edit: you're using Bitbucket's comparator, which is not git diff, and perhaps not even part of Git at all. It's not obvious what Bitbucket is doing here. It may or may not be looking at merge bases:

base=$(git merge-base $tip1 $tip2) git diff $base $tip2

However, I thought at one point that this is what GitHub was doing for pull request displays, and then experimentation provide that it isn't what GitHub does. It may not be what Bitbucket does either (nor whether what BitBucket's web-browser-based UI does is directly related to what GitHub's does in the first place).

Since I have no idea what Bitbucket is actually comparing—though it's clearly not the two branch tips—I can't really answer the rest of this. I'll leave the original answer in, below, since it might be useful to others who find this question and really are just running git diff on the command line.

The input to git diff is (to a first approximation anyway) two commits or two snapshots: compare this snapshot with that one.

The output from git diff is a set of instructions. These instructions tell you how to change the first snapshot, in order to get the second one.

This means your initial expectation is wrong. Git is not saying: To go from an older snapshot to a newer one, add these lines here and remove those there. It's saying: To go from the left side commit/snapshot to the right-side one... If you swap the sides, you'll get inverted directions: if changing snapshot A to snapshot G requires adding a line, changing snapshot G into snapshot A will require deleting that same line.

Improve this answer

1 Comment

I should clarify. I meant to say that the list of diff files are totally different. When I have master as my source there are a lot of files that where committed when I merged but when I had uat as my source there were only a couple of files that were committed

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.