Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-5356

Allow me to set a merge s="ours" point in the auto-merge chain

    • 13
    • 6
    • 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.

      In the merge dialog, Stash shows a list of the branches it's about to auto-merge into.

      There are some cases where you want to prevent those changes from being merged into a release branch - perhaps because there has been a refactor in a particular release and a different fix was applied already (or will be applied in the future by another branch and PR).

      This suggestion is for the ability to elect a branch where the change will stop propagating. The automerge will still technically propagate through all releases, but it will be a no-op change into that branch and all branches after it because the merge will be done with the "strategy=ours" option set.

            [BSERV-5356] Allow me to set a merge s="ours" point in the auto-merge chain

            Denis A. added a comment - - edited

            @Paul Draper, thank you for your response and example.

            My point is not to avoid merges, as this would result in the situation you described.
            Indeed, merge -s ours on the topic branch is the perfect solution in this case.

            However, the current auto-merge behavior is problematic in the following situation:

            1. developer #1 work on branch feature, then:
            2. create a Pull Request and merge feature into release0, the "Delete source branch after merging" checkbox is checked, so the feature branch is deleted
            3. when merging, Stash will automatically cascade to release1
            4. now, there is a merge conflict between release0 and release1
            5. developer #1 realizes that she do not want to propagate the changes from feature to release1 so she prepare to merge -s ours release0 into release1 (remember: the original feature branch was deleted)
            6. developer #2 make changes (bugfix) to release0, so the HEAD of release0 contains both feature and bugfix
            7. developer #1 pull release0 and release1 then merge -s ours release0 into release1
            8. changes from bugfix are not propagated to release1 and are silently lost. This can stay undetected for a long time.

            This look like a long list of steps but this happen quite often when you have a lot of developers making changes to release branches.

            The best solution IMHO is to have Stash detect auto-merge conflicts upfront and allow to stop merging at some defined point.

            Denis A. added a comment - - edited @Paul Draper, thank you for your response and example. My point is not to avoid merges, as this would result in the situation you described. Indeed, merge -s ours on the topic branch is the perfect solution in this case. However, the current auto-merge behavior is problematic in the following situation: developer #1 work on branch feature , then: create a Pull Request and merge feature into release0 , the "Delete source branch after merging" checkbox is checked, so the feature branch is deleted when merging, Stash will automatically cascade to release1 now, there is a merge conflict between release0 and release1 developer #1 realizes that she do not want to propagate the changes from feature to release1 so she prepare to merge -s ours release0 into release1 (remember: the original feature branch was deleted) developer #2 make changes ( bugfix ) to release0 , so the HEAD of release0 contains both feature and bugfix developer #1 pull release0 and release1 then merge -s ours release0 into release1 changes from bugfix are not propagated to release1 and are silently lost. This can stay undetected for a long time. This look like a long list of steps but this happen quite often when you have a lot of developers making changes to release branches. The best solution IMHO is to have Stash detect auto-merge conflicts upfront and allow to stop merging at some defined point.

            Lucid Software added a comment - - edited

            @Denis, the problem with that is any subsequent merges that do need to cascade further will pick up those earlier commits.

            For example, suppose the cascade is release0 -> release1 -> release2, and you want to merge feature into release0 and release1, but not release2.

                   C (feature)
                  /
            A - B - (release0)
                |\ 
                |  (release1)
                 \
                    (release2)
            
                   C
                  /|\
            A - B  |  (release0)
                |  |
                |   (release1)
                 \
                    (release2)
            

            Now someone wants to merge bugfix into all three

                     D (bugfix)
                    /
                   C
                  /|\
            A - B  |  (release0)
                |  |
                |   (release1)
                 \
                    (release2)
            
                     D
                    /|\
                   C | \
                  /  |  \
            A - B    |\   (release0)
                     | \
                     | (release1)
                     |
                     (release2)
            

            But now release2 also has C.

            There are two ways to have D in release2, but not C:

            1. merge each time, but use s=ours when we do not want the commit.
            2. don't merge; use cherry-picks

            The second way create copies of the commits, rather than linking to the commit and its entire history. It has the advantage of being more selective, and of not cluttering up the history with a bunch of merges. (If you have 10 branches, the last one has 10 merges stacked on.) The disadvantage is that you generally lose the ability to correlate the two changes, as it is just a copied patch.

            Lucid Software added a comment - - edited @Denis, the problem with that is any subsequent merges that do need to cascade further will pick up those earlier commits. For example, suppose the cascade is release0 -> release1 -> release2, and you want to merge feature into release0 and release1, but not release2. C (feature) / A - B - (release0) |\ | (release1) \ (release2) C /|\ A - B | (release0) | | | (release1) \ (release2) Now someone wants to merge bugfix into all three D (bugfix) / C /|\ A - B | (release0) | | | (release1) \ (release2) D /|\ C | \ / | \ A - B |\ (release0) | \ | (release1) | (release2) But now release2 also has C. There are two ways to have D in release2, but not C: merge each time, but use s=ours when we do not want the commit. don't merge; use cherry-picks The second way create copies of the commits, rather than linking to the commit and its entire history. It has the advantage of being more selective, and of not cluttering up the history with a bunch of merges. (If you have 10 branches, the last one has 10 merges stacked on.) The disadvantage is that you generally lose the ability to correlate the two changes, as it is just a copied patch.

            Denis A. added a comment - - edited

            The suggested work-around of using

            git merge -s ours

            is considered dangerous here because this can easily result in lost commits, i.e. not auto-cascaded to newer branches, when additional commits are appended automatically to the "Automatic merge failure" PR.

            A real "stop auto-merge here" feature would be safer and easier to use.

            (Edited to clarify)

            Denis A. added a comment - - edited The suggested work-around of using git merge -s ours is considered dangerous here because this can easily result in lost commits, i.e. not auto-cascaded to newer branches, when additional commits are appended automatically to the "Automatic merge failure" PR. A real "stop auto-merge here" feature would be safer and easier to use. (Edited to clarify)

            Lucid Software added a comment - - edited

            It is a very common situation to have fixes that only apply to some release branches.

            The current workaround, as suggested in the description, is before merging the pull requests, run

            git fetch
            git checkout oldest-branch-to-exclude
            git merge -s ours origin/feature-branch
            git push
            

            https://answers.atlassian.com/questions/9390955
            https://answers.atlassian.com/questions/10393733

            Lucid Software added a comment - - edited It is a very common situation to have fixes that only apply to some release branches. The current workaround, as suggested in the description, is before merging the pull requests, run git fetch git checkout oldest-branch-to-exclude git merge -s ours origin/feature-branch git push https://answers.atlassian.com/questions/9390955 https://answers.atlassian.com/questions/10393733

            UX is the biggest challenge here, but related to allowing custom merge strategies it might be possible to expose options along the entire merge chain (and ideally be a bit smart about allowable combinations...

            eg:
            source
            release/1.1 (default)
            release/1.2 (default)
            release/2.0 (ours) --noop starts here
            release/2.1 (ours)
            master (ours)

            Roger Barnes (Inactive) added a comment - UX is the biggest challenge here, but related to allowing custom merge strategies it might be possible to expose options along the entire merge chain (and ideally be a bit smart about allowable combinations... eg: source release/1.1 (default) release/1.2 (default) release/2.0 (ours) --noop starts here release/2.1 (ours) master (ours)

              Unassigned Unassigned
              aahmed Adam Ahmed (Inactive)
              Votes:
              27 Vote for this issue
              Watchers:
              20 Start watching this issue

                Created:
                Updated: