-
Suggestion
-
Resolution: Unresolved
-
None
-
None
-
64
-
Hi everyone,
Thanks for your feedback, passion, and advocacy for this suggestion. Please accept our apologies for allowing this issue to remain open without a clear answer from us.
Changing the way diff works (diff A B instead of git diff A...B) doesn't align with our product priorities.
We remain committed to being an open company, whether it's with regards to feature requests or bugs in our software.
What are we doing instead? We remain committed to helping software teams deliver high-quality software faster in an increasingly competitive world. We believe that great developer tools are a key element of modern software development. To that end, we've made a lot of improvements last year and are planning to work in the following areas that help with problems development teams face now:
- Performance and scaling to support growth
- Security and compliance features
- Innovations around developer productivity
- Integrations between Atlassian and other leading products
Cheers,
Anton Genkin
Product Manager - Bitbucket Data Center & Server
Original suggestion
If I have two branches with the same changes in different commits, Stash's branch comparison is misleading.
I have created a demonstration git repository (attached). In it, I created the file two.txt on both 'master' and 'a_branch'. I then made further modifications to this file on 'master'.
However, Stash's compare (see screenshot) is showing the line 'file two' as being a new addition when merging 'master' into 'a_branch'. Furthermore, it is claiming two.txt is a new file (it's shown in green text on the left panel), when it already exists in 'a_branch'!
In terms of git's CLI, I would expect this:
$ PAGER=cat git diff a_branch..master diff --git a/file_created_in_branch.txt b/file_created_in_branch.txt deleted file mode 100644 index d673e5e..0000000 --- a/file_created_in_branch.txt +++ /dev/null @@ -1 +0,0 @@ -created file in a_branch diff --git a/file_created_in_master.txt b/file_created_in_master.txt new file mode 100644 index 0000000..9dc7d06 --- /dev/null +++ b/file_created_in_master.txt @@ -0,0 +1 @@ +this file was only created in master! diff --git a/two.txt b/two.txt index 6c970db..135327c 100644 --- a/two.txt +++ b/two.txt @@ -1 +1,2 @@ file two +modification in master
However, Stash seems to be doing the equivalent of this (three dots!):
$ PAGER=cat git diff a_branch...master diff --git a/file_created_in_master.txt b/file_created_in_master.txt new file mode 100644 index 0000000..9dc7d06 --- /dev/null +++ b/file_created_in_master.txt @@ -0,0 +1 @@ +this file was only created in master! diff --git a/two.txt b/two.txt new file mode 100644 index 0000000..135327c --- /dev/null +++ b/two.txt @@ -0,0 +1,2 @@ +file two +modification in master
This has bitten our users several times: they become reluctant to create pull requests because they think the merge would include more changes than they expected. As a result, they lose trust in branch comparison tool.
- is duplicated by
-
BSERV-8213 As a stash user, I want compare to work correctly
-
- Closed
-
-
- Closed
- is related to
-
-
- Closed
-
- mentioned in
-
Page Failed to load
-
Page Failed to load
-
Page Loading...
-
-
-
-
-
-
-
-
-
-
-
- resolves
-
[BSERV-7375] Stash's branch compare starts at a common ancestor, so the diff shown is misleading
At this stage its safe to say they would rather have you go to a competitor than fix this. I'm sure the reasoning is that they just don't think they will ever beat github or gitlab and so they are not investing in Bitbucket anymore since it isn't profitable. In the foreseeable future they will block new repos from being created like AWS did with CodeCommit.
If you (Atlassian) don't want to change the default behaviour of the diff, then make it a setting and have the current way of doing it as the default.
Then those of us that want to diff in other ways can do so.
The options would be:
diff A...B (default)
diff A B
The diff view of a pull request must show the target branch changes that will result from merging the PR.
If the diff view shows something else, that's a bug by definition.
If it helps to increase priority, today I also ran into a incorrect diff that reported no differences between a file in two branches, but the files were different. This is very annoying because important updates where not merged into the relevant branch. We might reconsider moving all our repositories to bitbucket.
Echo on everything above. I've already been through conversations with Bitbucket about this, but it would be disappointing if Atlassian perceived a lack of activity on this particular thread as somehow a lack of importance. So chiming in here.
Well put by Mr. Neville – "Unfortunately for us, this inconsistency has burned hours of development time to troubleshoot and ultimately erodes trust in the system and we will be reducing our usage of Bitbucket pull requests as a result."
It seems like Atlassian is not intersted in implementing this and they might have reasons. I get that and we seem to be required to just accept it. As always in IT, proper and easy to find documentation is key for users, developers and admins.
My suggestion would be, to show direct links to the documentation on every location in Atlassian Bitbucket that shows diffs. That is, from the top of my head, the pull request diff-view and the "compare branches" view. I'm sure there is other locations as well.
In my opinion that would at least help reduce the risk of dangerously misleading people, which had happenend in my team.
It would make them think twice whether they can trust the diff they are looking at or not. For exacmple, a user who had cherry-picked changes into the target before would be warned that what they are seeing is not true / is another type of diff. Also sometimes merging in the target branch into the source in e.g a PR helps to finally get a useful and trustworthy view. It might help to include such a hint in that suggested links to the docs.
And as the original reporter of this issue implied and as it happened in my team as well. People now don't trust Atlassian diffs anymore which slows down PR reviews and making decisions. It could help to make documentation as obvious as possible for all users, even those that might not have gotten the memo...
We ran into this issue today and it took a long time to understand why the output of `git diff` and the resultant `git merge` locally was misaligned with what Bitbucket pull requests were indicating. It's incredulous to think this crucial workflow is somehow not a top priority to allow, at the very least, configurability in a drop down.
Unfortunately for us, this inconsistency has burned hours of development time to troubleshoot and ultimately erodes trust in the system and we will be reducing our usage of Bitbucket pull requests as a result.
It doesn't help if you work on performance when you can't rely on the basic functions. So you don't have your priorities right.
Currently the user selects two branches, then the tools shows the two top of stack commit IDs but below it doesn't compare these two commits, but it uses one "unknown" commit.
This behavior is simply dangerous for software development, and it doesn't help if a good performance allows you to run faster into this error.
Echoing everything in the above - this is confusing our developers and we would like to have another diff visualization that does direct branch comparison instead of going back to the common ancestor.
Hello, Why I find disturbing is thta the GUI does not show the good commit id used for that diff.
See that drawing I made to explain the problem (below)
At the minimum, GUI should not mislead user with that no used at all commit ID...
(as discussed here => https://community.atlassian.com/t5/Bitbucket-questions/Git-diff-show-different-files-than-PR-Pull-Request/qaq-p/2331786#U2606430)
EDIT : Oh well I cannot attach picture... See the drawing on given link...