Bug #5561
open
PR diff doesn't update when target changes
0%
Description
Hi,
I have a git repository with a PR submitted to the master branch. A user then pushes commits to the git repository that updates the commit to which master points. Now the diff displayed in the PR is out of date and includes changes that are already accepted on master. I expect the diff to be the equivalent of git diff target...source even when the target pointer is updated.
For example, I see the issue with the following history:
* 8c5e00f - (4 hours ago) Commit 2 (B/bug)
| * e74c974 - (6 hours ago) Merge pull request #5 (origin/master)
| |\
| |/
|/|
* | 0bd6161 - (28 hours ago) Commit 1
|/
* c02d23d - (11 days ago) Commit 0 # origin/master was originally here
A PR was submitted from B/bug to origin/master when origin/master pointed to c02d23d and the displayed diff was correct. Then origin/master was updated to point to e74c974 and now the PR displays the wrong diff. Specifically the common ancestor was not updated so the PR diff shows 0bd6161 and 8c5e00f instead of just 8c5e00f like it should.
I'm using RhodeCode Enterprise 4.17.2.
Regards,
Evan
Updated by Marcin Kuzminski [CTO] over 5 years ago
Hi Evan,
Have you tried to force refresh the PR using the merge box ? Since 4.17.X there's a special link to refresh the diff.
Updated by Evan Ward over 5 years ago
Hi Marcin,
Yes, I tried that but it had no effect.
Updated by Marcin Kuzminski [CTO] over 5 years ago
Just to take one item from the equation, in repository settings (the target repo) under caches > Diff Caches can you remote the directory which starts with .__shadow_diff_cache. We want to check if it's maybe not related to cached diff
Updated by Evan Ward over 5 years ago
In that directory there appears to be one file related to the PR. It is pull_request_457_latest_latest_8c5e00f22791db8df3d724e67611514b53d1a418_c02d23dc971e6f31aa17b620737b2a85d21fac4b_False_3_False. Those hashes match the first and last commits above. It contains several copies of the files involved in commits c02d23d, 0bd6161, and 8c5e00f. Is that the information you're looking for?
Updated by Marcin Kuzminski [CTO] over 5 years ago
Yes, can you delete this file (It's just a diff copy, it will be recreated on the first visit) and check the diff again ?
Updated by Evan Ward over 5 years ago
I deleted the file and then refreshed the PR. It had no effect on the diff. The cache file was recreated as you predicted.
I also tried creating and new PR from B/Bug to origin/master and it still shows the same diff, unexpectedly including the changed files from 0bd6161. Perhaps the "Update Commits" step I listed in the original report is a red herring.
Updated by Evan Ward over 5 years ago
Sorry, instead of "Update Commits" I meant to say the step where the master branch of the target repository is updated.
Updated by Marcin Kuzminski [CTO] over 5 years ago
Yes, so if the "new" PR diff is also considered incorrect this is a different problem. The main assumption till now was the update changes the diff in an unexpected way. We'll check same example as your graph to verify everything is ok with calculating common ancestor and a diff.
Updated by Marcin Kuzminski [CTO] over 5 years ago
I meant to say the step where the master branch of the target repository is updated.
There's a logic when you hit "update commits" button that also should check about that, and a green flash message would indicate that PR was updated because of source OR target changed (two different messages)
Updated by Redmine Integration over 4 years ago
- Status changed from New to Resolved
Commit 4dcd6440307c by Marcin Kuzminski marcin@rhodecode.com on default branch changed this issue.
https://code.rhodecode.com/rhodecode-enterprise-ce/changeset/4dcd6440307ce57cb73a08ed480d184b26227628