Live-share: Allow guests to perform source control operations in VS and VS Code

[Chuxel]

Note that developers starting the collaboration session (owners) do not have this limitation. It is specific to guests joining a session.

Related to #36

Currently source control features like those found in the VS Team Explorer and the VS Code Source Control tabs do not function for guests joining a collaboration session as they rely on local files to work.

We should consider doing the extra work required to allow guests to execute source control operations (commit/checkin, pull, push, etc) on behalf of the owner if there is sufficient interest.

[andrewbranch]

This would be really interesting. So I'd be able to commit a file that exists on the host’s machine _as myself_?

[Chuxel]

@andrewbranch That is one option. However, one challenge is that you committing as yourself would also pick up other guests (or the host's) edits as your own. That could be tricky when using something like git blame to figure out who to talk to about something (along with traceability in general).

Another we could consider here is to instead rather than exposing the ability to commit on another's behalf is to provide a way to have a log of those that contributed to a given commit across even multiple sessions that then flows along with the commit message automatically.

This has a couple advantages. First, it avoids the problems above. Second, it lets people know that others have reviewed aspects of the commit when the PR is created which should speed up any reviews (e.g. if we could surface this at PR time). Finally, in true pair programming scenarios where the code really is "owned" by multiple people it gives visibility to who each of them are.

Thoughts on whether this is a preferable model?

[andrewbranch]

I would think it's possible to do both. The latter sounds great, and could be done in conjunction with the former, whether guests and hosts are both choosing to commit or just the host is committing. But I tend to think that per-collaborator commits could be done well, since VS Code already has a great UI for staging files and parts of files (at least, I think I've seen this feature). I'm a command-line-only git user, but if I were a guest in a collaboration session, I'd be content to use Code's UI to stage and commit small chunks. That would eliminate the likelihood that a guest would inadvertently commit large amounts of other people's edits with a sweeping command like git commit -a.

I can see that working for some people and not for others. If this were a feature, it would probably be nice to let the host control whether or not guests have any control over source control.

[hugo-retro]

This is the current scenario we are running in. Traceability is a huge factor in order to resolve issues faster since the best person to ask about a specific line/segment of code is the actual person who wrote it. Is it even possible to allow the host to make a sweeping commit but have git blame still show the individual contributors?

[CilliersN]

Yes!!! We need git blame to be incorporated into the sessions, please.
If person A collaborates on person B's session and person B makes a commit via source control.
Would it be possible to have person A's name/trail to the line/code segment that he wrote?

[mittalyashu]

First of all, thanks for this feature.

Now, some feedback...

Git is one of the most important part of the coding where we can version control the source code, but if someone messes with it, there can be catastrophic situations. That's why we need to set some restriction on who get to commit, stash, pull, push, and all other git commands.

Now, just by setting the restrictions in VS Source control tab is not sufficient, if the owner _(person who starts the collaboration session)_ has shared a terminal then guests have easy access to git commands.

There can be a whole separate discussion for permissions, but I will keep it short and say that we can illustrate it the form of table, where we can control the permission.

| NAME | Commit | Stash | Pull | Push |
| --- | --- | --- | --- | --- |
| Yashu | ✅ | ✅ | ✅ | ✅ |
| Chuxel | | | ✅ | |

Managing permission for individual guest can be a tedious work, there can be other way by assigning roles and categorising the git features based on the roles.

| Role name | Git features |
| --- | --- |
| Read only | git pull |
| Write | git commit |
| Edit | git revert |

For past few months I have notice that Live share no longer create a directory .vsls. We can use similar concept to store permissions, instead of storing live sharing permission in a separate file, it's good to store it in a single roof .vscode/settings.json

"ls_settings": {
     "git_control": true // enable guests to use git
     "permission": {
          "mittalyashu": "read only"
           "chuxel": {
              "commit": true,
              "pull": false
          }
     }
}

_Hope this explains_ 😄

[lostintangent]

I'm going to close this for now since we haven't heard significant customer feedback for this over the last (almost) 3 years, and there's an easy workaround: sharing a read/write terminal. If this is something that folks would like to see us prioritize, please let us know by re-opening/commenting on this bug. Thanks!

[SpaceForever]

This is something I would like to see prioritized!

[lostintangent]

@spaceforever Hey! Would you be able to share a bit about your use case? And just to confirm: a read/write terminal wouldn't be sufficient? Thanks!