Branches support

[vors]

Any story for read/write from/to non-default branches/tags?

[weswigham]

Possibly

I was considering it before but couldn't think of a (good) way to expose it. I was toying with the idea of a Set-GHBranch cmdlet which sets an environment variable which the provider then reads, but there's no solid way to reset that when you leave a repo/access a file in a new repo. Maybe it would be best if it was an optional part of the path? Github itself deals with this by saying tree/<branchname> in the URL (and requiring tree/<defaultbranch> in ambiguous cases). I don't particularly like it unless I can guarantee that you don't have to specify the branch, though.

It might be best if I adopt the syntax npm uses and allow <org>/<repo>#<branch>. That could work fairly well for branches. Specifying out a specific commit or tag only works in the readonly case, since making a change would advance the branch you were on.

[vors]

I really like how GithubProvider express itself purely via PS Provider, so it would be nice to avoid introducing any cmdlets for common scenarios.

Configuration for branches can be preserved as a map in the provider state instead of $env: variable.

One option would be introducing a new level in the hierarchy:
GH:\vors\ZLocation\LICENSE become GH:\vors\ZLocation\master\LICENSE
or GH:\vors\ZLocation\branch\master\LICENSE

I understand that it's verbose, but it can be worked out with graceful default behavior: if appropriate branch not founded, fall back to assumption that default branch is used.

Then, if somebody doing cd GH:\vors\ZLocation, the result path can be GH:\vors\ZLocation\branch\master.

I can see problems with IntelliSense for <org>/<repo>#<branch> approach.