1

In a private repo I created a PR to merge changes from dev into master. The PR shows 168 to be merged automatically - I proceeded with merge and all was ok.

I then created another PR to merge changes from dev to master - I expected 0 files as I had just merged, however it showed the same 168 files, curious I proceeded with the merge and when I looked at the commit, it showed 0 files

enter image description here

enter image description here

This wasn't across a fork - just 2 branches in the same repo - can anyone explain why the PR showed 168 files - was this a caching issue?

markpirvine
  • 1,485
  • 1
  • 23
  • 54

1 Answers1

0

The difference between the number of files to be merged and actually merged (0) does indeed point out to a cache issue on the remote side.

I would test the caching issue by making the second PR a day after the first, and checking that 0 (or only a few file if you have pushed new commits on dev) show up.

If the PR does a three-dots comparison (using the base commit), not that since Sept. 2018, you can also do, from GitHub, a two-dots comparison.

See more with:

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for your reply, I've been reading a lot about how GitHub build the diff and they use a three-dot diff which would produce the results I'm seeing (https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-comparing-branches-in-pull-requests#three-dot-and-two-dot-git-diff-comparisons). – markpirvine Mar 19 '20 at 06:48
  • @markpirvine True. I have edited the answer with links to GitHub help pages documenting the two vs. three dots diff. – VonC Mar 19 '20 at 07:24
  • it seems I need to make a change in my approach to git - either continue to squash merge to master and put up with the three-dot diff, change the url each time to use the two-dot diff (don't see an option to make this the default) or stop squash merging to master... – markpirvine Mar 20 '20 at 07:31