Uploaded image for project: 'Bitbucket Server'
  1. Bitbucket Server
  2. BSERV-7375

Stash's branch compare starts at a common ancestor, so the diff shown is misleading

    XMLWordPrintable

Details

    • 962
    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

    Description

      Atlassian status as of Mar 2022

      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.

      Attachments

        1. git_hist_test.tar
          90 kB
        2. stash_compare_crop.png
          stash_compare_crop.png
          87 kB

        Issue Links

          Activity

            People

              Unassigned Unassigned
              5ba9f01dded3 Wilfred Hughes
              Votes:
              109 Vote for this issue
              Watchers:
              92 Start watching this issue

              Dates

                Created:
                Updated: