Adds IncludeCommits switch to Get-VSTeamPullRequest

[danstur]

PR Summary

Currently Get-VsTeamPullRequest does not offer a way to get the commits of a specific pull request. Here's a simple implementation that works fine for me with Azure DevOps Server (on-premise).

Open Questions

• Not sure if simply adding RepositoryId to the ById parameter set is the best approach.
• Do I need a types file for the git commit ref? (msdn)
• Since the pull request ID is only known after I create this, I guess I should update the changelog and rebase afterwards? :-)
• Trying to run the Script Analyzer results in:

  Invoke-ScriptAnalyzer: C:\dev\OpenSource\vsteam\Build-Module.ps1:149:9
  Line |
  149 |     $r = Invoke-ScriptAnalyzer -Path $output -Recurse
   |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   | Object reference not set to an instance of an object.

  (Windows 10 x64, PowerShell 7.0). So I couldn't run the analyzer to see if I violated any rules - given the minimal changes I hope not.

PR Checklist

• [x] Write Help
• [x] Write Unit Test
• [x] Update CHANGELOG.md

[danstur]

Fixed comments from CR.

• How did you call the script? Just on Windows 10 1909 with Pwsh Core:

  Name                           Value
  ----                           -----
  PSVersion                      7.0.2
  PSEdition                      Core
  GitCommitId                    7.0.2
  OS                             Microsoft Windows 10.0.18363
  Platform                       Win32NT
  PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
  PSRemotingProtocolVersion      2.3
  SerializationVersion           1.1.0.1
  WSManStackVersion              3.0

  the following happens:

  
  C:\dev\OpenSource\vsteam [master ≡]> .\Build-Module.ps1 -installDep -ipmo -analyzeScript
  Processing: functions in C:\dev\OpenSource\vsteam\Source\_functions.json
  Creating: C:\dev\OpenSource\vsteam\dist\vsteam.functions.ps1
  Processing: types in C:\dev\OpenSource\vsteam\Source\types\_types.json
  Creating: C:\dev\OpenSource\vsteam\dist\vsteam.types.ps1xml
  Processing: classes in C:\dev\OpenSource\vsteam\Source\Classes\_classes.json
  Creating: C:\dev\OpenSource\vsteam\dist\vsteam.classes.ps1
  Processing: formats in C:\dev\OpenSource\vsteam\Source\formats\_formats.json
  Creating: C:\dev\OpenSource\vsteam\dist\vsteam.format.ps1xml
  Publishing about help files
  Updating Functions To Export
  Publish complete to C:\dev\OpenSource\vsteam\dist
  Starting static code analysis...
  Invoke-ScriptAnalyzer: C:\dev\OpenSource\vsteam\Build-Module.ps1:189
  Line |
  189 |     $r = Invoke-ScriptAnalyzer -Path $output -Recurse
   |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   | Object reference not set to an instance of an object.

Static code analysis complete.

I assume some version conflict with some referenced modules, but haven't looked too much into it yet.

[SebastianSchuetze]

@danstur one side question. Is there a specific reason why you are doing a force-push? :-) Force pushes are usually not considered a best practice when working with multiple people in a project.

[danstur]

Force pushes to shared branches are an awful idea and anybody doing them should be taken out and shot I agree ;-) Force pushes to private branches when rebasing code to keep commits clean don't have the problems - nobody else is working on my private branch after all.

I like to get multiple small commits into origin when working to have backups and be able to switch back and forth, but I'm sure you only want a single commit in upstream. There might be (most certainly is, Azure DevOps has at the very least) some GitHub specific solution to this, that avoids the need to rebase manually if you only want a single commit in upstream from this PR.

Not sure how you'd avoid force pushes if you want to rewrite history to have several nice, clean, separate commits if this was a longer PR with say multiple stages that deserve separate commits.

How would you approach this? I'm always interested in learning other people's workflows.

[SebastianSchuetze]

The same is for us, that is why I always merge the PR here with a squash merge: https://github.blog/2016-04-01-squash-your-commits/

Had the same problem and I wanted to have a cleaner history.

[danstur]

Ah yes, so the same as with Azure. Yeah that works great if you want every PR to be a single commit - for larger PRs a more fine-grained history might be desirable though so I somewhat got in the habit of doing what GitHub does itself when it squashes the commits myself.

Admittedly for a tiny change like this no point really :-)

[danstur]

Anything else you need me to do for this to be merged into master?