Skip to content
This repository was archived by the owner on Jun 21, 2023. It is now read-only.

Conversation

jcansdale
Copy link
Collaborator

The PR's base branch might well have moved on since the PR was originally created. The PR head should be compared against the merge base between the PR base and head.

  1. Check if merge base can be found between base and head SHAs.
  2. If it can, diff using local merge base and PR head files.
  3. If it can't, fetch the PR's base and head branches.
  4. Find merge base and diff against PR head file.

This means at most one fetch is required before the PR files can be explored without hitting the network again. 😄

Fixes #1007

jcansdale added 7 commits June 8, 2017 12:27
We need to compare the file from when it originally branched, not from the current state of the branch.
It will fall back to using the base if the merge base can't be found (this can happen if the PR branch doesn't exist in the local repo). This needs to be fiixed.
Use 'refs/pull/{PR}/head' because it's defined in current repo (so don't want to add a new remote).
The PR head is now being fetched so should be available in local repo.
Abstract away interactions with LibGit2Sharp.
@jcansdale jcansdale added the bug label Jun 12, 2017
{
[Export(typeof(IGitClient))]
[PartCreationPolicy(CreationPolicy.Shared)]
[NullGuard(ValidationFlags.None)]
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if I still need this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leave it on there, NullGuard being enabled causes more problems than it solves IMO and we will hopefully remove it soon.

Copy link
Contributor

@grokys grokys left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! CI seems to be failing though?

try
{
// Can't use Assert.Throws because ExtractDiffFiles is async.
await ExtractDiffFiles(baseSha, baseFileContent, headSha, headFileContent, mergeBaseSha, mergeBaseFileContent,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't you use Assert.ThrowsAsync here?

{
// Can't use Assert.Throws because ExtractDiffFiles is async.
await ExtractDiffFiles(baseSha, baseFileContent, headSha, headFileContent, baseSha, baseFileContent,
fileName, checkedOut);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Likewise here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like you can indeed. I hadn't noticed Assert.ThrowsAsync before. Thanks for the tip!

@jcansdale jcansdale merged commit 0d04613 into feature/inline-reviews Jun 13, 2017
@jcansdale jcansdale deleted the fixes/1007-use-merge-base branch June 13, 2017 14:41
suo added a commit to pytorch/pytorch that referenced this pull request Oct 28, 2019
…hing"


Okay, my last fix was wrong because it turns out that the base SHA is
computed at PR time using the actual repo's view of the base ref, not
the user's. So if the user doesn't rebase on top of the latest master
before putting up the PR, the diff thing is wrong anyway.

This PR fixes the issue by not relying on any of these API details and
just getting the merge-base of the base and head refs, which should
guarantee we are diffing against the right thing.

This solution taken from github/VisualStudio#1008

Differential Revision: [D18172391](https://our.internmc.facebook.com/intern/diff/D18172391)
suo added a commit to pytorch/pytorch that referenced this pull request Oct 28, 2019
…hing"


Okay, my last fix was wrong because it turns out that the base SHA is
computed at PR time using the actual repo's view of the base ref, not
the user's. So if the user doesn't rebase on top of the latest master
before putting up the PR, the diff thing is wrong anyway.

This PR fixes the issue by not relying on any of these API details and
just getting the merge-base of the base and head refs, which should
guarantee we are diffing against the right thing.

This solution taken from github/VisualStudio#1008

Differential Revision: [D18172391](https://our.internmc.facebook.com/intern/diff/D18172391)
suo added a commit to pytorch/pytorch that referenced this pull request Oct 28, 2019
…hing"

Okay, my last fix was wrong because it turns out that the base SHA is
computed at PR time using the actual repo's view of the base ref, not
the user's. So if the user doesn't rebase on top of the latest master
before putting up the PR, the diff thing is wrong anyway.

This PR fixes the issue by not relying on any of these API details and
just getting the merge-base of the base and head refs, which should
guarantee we are diffing against the right thing.

This solution taken from github/VisualStudio#1008

Differential Revision: [D18172391](https://our.internmc.facebook.com/intern/diff/D18172391)
suo added a commit to pytorch/pytorch that referenced this pull request Oct 28, 2019
…hing"

Okay, my last fix was wrong because it turns out that the base SHA is
computed at PR time using the actual repo's view of the base ref, not
the user's. So if the user doesn't rebase on top of the latest master
before putting up the PR, the diff thing is wrong anyway.

This PR fixes the issue by not relying on any of these API details and
just getting the merge-base of the base and head refs, which should
guarantee we are diffing against the right thing.

This solution taken from github/VisualStudio#1008

Differential Revision: [D18172391](https://our.internmc.facebook.com/intern/diff/D18172391)
suo added a commit to pytorch/pytorch that referenced this pull request Oct 28, 2019
…hing"

Okay, my last fix was wrong because it turns out that the base SHA is
computed at PR time using the actual repo's view of the base ref, not
the user's. So if the user doesn't rebase on top of the latest master
before putting up the PR, the diff thing is wrong anyway.

This PR fixes the issue by not relying on any of these API details and
just getting the merge-base of the base and head refs, which should
guarantee we are diffing against the right thing.

This solution taken from github/VisualStudio#1008

Differential Revision: [D18172391](https://our.internmc.facebook.com/intern/diff/D18172391)

ghstack-source-id: 90e1fad
Pull Request resolved: #28798
suo added a commit to pytorch/pytorch that referenced this pull request Oct 28, 2019
…hing"


Okay, my last fix was wrong because it turns out that the base SHA is
computed at PR time using the actual repo's view of the base ref, not
the user's. So if the user doesn't rebase on top of the latest master
before putting up the PR, the diff thing is wrong anyway.

This PR fixes the issue by not relying on any of these API details and
just getting the merge-base of the base and head refs, which should
guarantee we are diffing against the right thing.

This solution taken from github/VisualStudio#1008

Differential Revision: [D18172391](https://our.internmc.facebook.com/intern/diff/D18172391)
facebook-github-bot pushed a commit to pytorch/pytorch that referenced this pull request Oct 28, 2019
Summary:
Pull Request resolved: #28788

Okay, my last fix was wrong because it turns out that the base SHA is
computed at PR time using the actual repo's view of the base ref, not
the user's. So if the user doesn't rebase on top of the latest master
before putting up the PR, the diff thing is wrong anyway.

This PR fixes the issue by not relying on any of these API details and
just getting the merge-base of the base and head refs, which should
guarantee we are diffing against the right thing.

This solution taken from github/VisualStudio#1008

Test Plan: Imported from OSS

Differential Revision: D18172391

Pulled By: suo

fbshipit-source-id: 491a50119194508b2eefa5bd39fe813ca85f27b1
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants