nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Why does the diff in the PR does not reflect active state of the target branch

Mike Kessler

Situation - 3 branches branch1,branch2,branch3 are all based on branch1 at start.

add a file in branch2 named abc.txt, commit, push

add a file in branch3 named cba.txt, commit, push

create a pull request (PR1) from branch2 to branch1, the diff shows abc.txt is a new file

create a pull request (PR2) from branch3 to branch1, the diff shows cba.txt is a new file

merge PR2

Conceptually, PR1, if diffed to branch1 should now show abc.txt is a new file AND that cba.txt does not exist. If I was to do this same comparison using meld on my computer, it would show this diff, however it only shows that abc.txt is a new file in Stash.

Why would this be? I looked around stash config properties and cannot seem to find a setting that would identify this diff. Is there a way to achieve this, or at minimum identify that it's not a fast-forward (without changing the merge strategy)?

Accepted answers

TimP

Hi Mike,

This is because Stash is showing you the result of merging the pull request PR1 (merging branch2 into branch1), rather than a traditional diff between the two. We believe that seeing the actual result is the most useful thing to see in a pull request as it represents the actual content of the repository after you hit the merge button.

Identifying whether or not the Pull Request is a fast-forward merge or not is an interesting idea though. If this is because you want to ensure that merges are always fast-forwards you may be interested in the advanced Pull Requests config properties which will allow you to enforce fast-forwards or automatically squash branches when merging. If you want to identify fast-forwards for some other reason, I'd recommend raising an issue in the Stash project at https://jira.atlassian.com.

cheers,

Tim

All comments

TimP

Hi Mike,

cheers,

Tim

Mike Kessler

We don't want to change the merge strategy to ff only, mostly because if we went to an only-fast forward merge strategy, then merges wouldn't contain an additional commit, which we use as part of our workflow.

Yes, providing knowledge of whether a PR is fast forward or not is definitely desireable, and I've considered writing my own plugin (when I find the time) to do so - but I'd really rather just see the diff in stash as it would show up in any compare tool. This is mostly because different engineers use different tools to perform diffs, and I'd rather people be comparing apples to apples.

From what I gather from your response, there's not a good alternative approach currently, unless you have another suggestion?

Thanks for the help.

Bryan Turner

Mike,

I'm one of the Stash developers, and was involved in building our pull request diff algorithm. As Tim has said, Stash is showing you the merge's diff. This behavior is not configurable; it is intrinsic to how our pull requests work.

A diff-to-the-common-ancestor, as shown in other systems, would also not provide the diff you're looking for, as I understand it. It sounds like what you're looking for is a point-to-point diff, directly comparing the target commit with the source. We've found that, for most users, that type of diff is full of unexpected noise, file states that don't (immediately) make sense. In your example, a point-to-point diff between branch1 and branch2 after branch3 is merged would show cba.txt as deleted. To most users, that doesn't make sense. branch2 didn't remove cba.txt (in fact, it didn't interact with that file at all), so they perceive a diff like that as misleading. I'm not aware of any other hosting platform (Bitbucket et al) that will show such a diff. (Tools, on the other hand, will naturally let you diff any two commits you want, so I'm sure most of them can produce the diff you're describing.)

Hopefully this helps explain why the system is the way it is. I'm sorry we don't have a better solution for your use case, currently. As Tim suggested, raising a feature request at jira.atlassian.commight get that changed.

Best regards,
Bryan Turner
Atlassian Stash

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

bitbucket

bitbucket-server