Project

General

Profile

Bug #5561

PR diff doesn't update when target changes

Added by Evan Ward 2 months ago. Updated 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
13.08.2019
Due date:
% Done:

0%

Estimated time:
Sorting:
Commit Number:
Affected Version:

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

History

#1 Updated by Marcin Kuzminski [staff] 2 months 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.

#2 Updated by Evan Ward 2 months ago

Hi Marcin,

Yes, I tried that but it had no effect.

#3 Updated by Marcin Kuzminski [staff] 2 months 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

#4 Updated by Evan Ward 2 months 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?

#5 Updated by Marcin Kuzminski [staff] 2 months 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 ?

#6 Updated by Evan Ward 2 months 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.

#7 Updated by Evan Ward 2 months ago

Sorry, instead of "Update Commits" I meant to say the step where the master branch of the target repository is updated.

#8 Updated by Marcin Kuzminski [staff] 2 months 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.

#9 Updated by Marcin Kuzminski [staff] 2 months 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)

Also available in: Atom PDF