LICENSE Picker

[tonysneed]

I like that I can easily publish a local repo to GitHub, but it seems I always have to go back to add a LICENSE from the web site, where I can use the License Picker. It would be great to be able to pick a license type and add it from the GH extension for VS 2015.

[shana]

Hmmm, where would we put this...

If you create the repository from the extension, you can add the license (it's the same process as creating the repo on the website). It just creates the repo with a license file copied from a template on the website and clones it. There's no actual information attached to a repository about what license it has or doesn't have.

If we allow choosing a license on the publish form, right before publishing, we'd have to add the file to the repo and do a commit with it behind the scenes, and we'd have to ask the user about it so they don't get confused about why we're messing with the repo.

[haacked]

Great questions @shana.

I was thinking that having it during repository creation is a no-brainer. We do that on github.com and we should do that on both GHfVS and GHD.

But for an existing repository, it's definitely trickier. Another option is to have a menu option where you can choose to add a license, we show a picker, and then it just drops the file into the repo.

Creating commits on behalf the user when the working dir could be in a variety of states gets a bit gnarly and I'd rather do a simpler solution first.

@tonysneed are you mostly thinking about this from the perspective of adding a license to an existing repository?

Also, are you aware of https://addalicense.com/?

[shana]

I was thinking that having it during repository creation is a no-brainer. We do that on github.com and we should do that on both GHfVS and GHD.

We already do that on GHfVS, I just checked. As you said, no-brainer there :smile:

[haacked]

LOL! I checked GHD and assumed because it's not there it's not in GHfVS. I guess we should backport that, eh?

[shana]

We totally need to implement reaction gifs for comments, I wanna do a :metal: on that.

[tonysneed]

OK, I see what's happening now. The way to select a license locally is to go to the Connect tab of Team Explorer and click the Create link.

A dialog appears in which a license can be selected.

This is going to create a remote repo on GH with a License and .gitignore, but I'm then going to need to clone the repo, just as I would if I had created the repo from the web site.

But if I have an existing local repo, the license picker is not available.

The ideal would be a way to create a license locally by selecting from a license picker, then the user would add and commit the file before syncing. But I don't see a place in GHfVS where that could be done.

Another approach might be to put a license picker on in the GitHub section of the Sync tab, which allows the user to select a license that gets created in the remote repo when the user clicks the Publish button, in much the same way as the license is added from the Create dialog. Publish would then do a sync (push and pull), which would bring the license down.

What do you guys think?

[shana]

The ideal would be a way to create a license locally by selecting from a license picker, then the user would add and commit the file before syncing. But I don't see a place in GHfVS where that could be done.

There's very little areas in GHfVS where that would make sense to be done, and we can't hook into the project creation dialogs of VS to add stuff like that.

We could add a context menu entry in the solution explorer, maybe at the project level, but discoverability is really bad with that.

We could add a section in the Changes pane of Team Explorer to suggest adding a license, since that pane has the commit box and list of changed files to commit, but since the pane extends infinitely down for the file list, chances are we would have to dock it to the top and that would mess with the UI (which is not ours).

We could add something to the Team Explorer home page in our section (where the project information is), but even though that is the only area that is closer to a "Source control project management area", it's not really used for that right now, it's just used for showing information about the repository and entry points to solutions contained within it.

Another approach might be to put a license picker on in the GitHub section of the Sync tab, which allows the user to select a license that gets created in the remote repo when the user clicks the Publish button, in much the same way as the license is added from the Create dialog. Publish would then do a sync (push and pull), which would bring the license down.

In the creation dialog, the repository gets created remotely from scratch and then cloned, which is why we're able to add the license at that point. If you're publishing a local repository to GitHub, there is no remote repo, and we can't create one with the license because you already have changes to push in the local repository.

The Sync pane would definitely the best place for it, it's the most discoverable and appears at the right time, but the repository could be in any state at that point so we can't do it automatically.

---

In retrospect, I think adding something like "Add a license" to the project information area in the Team Explorer home section might be a good compromise. The problem is conveying the information that we can add the file with the license in the local directory, but the user has to 1) commit it and 2) push to make it stick. Until we have our own GitHub pane where we can show more actions and information about your active repository, adding things like this is going to be a pain.

[tonysneed]

In the creation dialog, the repository gets created remotely from scratch and then cloned, which is why we're able to add the license at that point. If you're publishing a local repository to GitHub, there is no remote repo, and we can't create one with the license because you already have changes to push in the local repository.

Wondering why this would not be possible when the user clicks Publish with a selected LICENSE from the Sync pane:

1. Create remote repository (same as Create)
2. Add selected License (same as Create)
3. Push to the newly created remote (same as Publish)
4. Pull from the remote to bring down the newly created LICENSE

Sorry if I'm missing something here, just trying to get a better understanding. :smile:

[shana]

@tonysneed The problem is that if we create the repository remotely and add a commit to it (by adding the license file), the history between the local and the remote will diverge with no common base. They will be, essentially, two completely different repositories with completely different histories and content. It's not possible to push a local repository to an existing remote repository if the commit hashes don't match - the only way to do it would be to force the push, which would rewrite the remote commits (so essentially the license commit would be gone as soon as you did step 3. in your scenario).

To merge the two conflicting histories, we would have to fetch the remote changes and rebase them locally behind the scenes. There are two problems with that:

1. The local working directory might not be in a state that allows us to rebase. Rebases have to be done locally in a clean working directory, because the way it works is that git "physically" removes all the local commits, applies the remote commit, and then reapplies all the local commits again on top of the remote one, thus reordering and rewriting history. It's totally possible to publish a repository with local changes that haven't yet been committed, as long as there is one commit in the history. Without a guarantee of a clean working directory, we can't change the history of the local repository automatically to add a commit with the license without direct user intervention.
2. Potential conflicts with existing local commits when rebasing: the user adds a license file in an earlier commit and then deletes it later, before publishing. We don't see any license file locally so we allow the user to select one. When git reapplies the existing commits, the earlier license commit conflicts with the one coming from the remote. Now the user is faced with resolving a conflict right in the middle of trying to publish a repository, which is an action that would seemingly have no impact locally (why would it?). The conflict is avoidable by applying the remote license commit on top of the existing history, instead of at the bottom, but then you'll have a part of the history that doesn't have any license, and that might or might not be what you want (retroactivity of licenses and what not).

The points of failure in this process are high. Adding a new file to an empty repository template at the time of creation is fine, but when there's already content, we can't do it automatically behind the scenes, it has to be done with some user intervention. We can help in adding the file to the local repository and guide the user to creating a commit for it, and we can even create the commit ourselves, but it always has to be done directly at the behest of the user and not as a part of an automated background process, so it's clear what's happening and the user can fix any issues that occur.

[tonysneed]

@shana Thanks, very clear explanation. So here's what I think at this point. Adding a LICENSE to a project is not really a GH thing. It seems like a feature for the VS Git integration team to consider, because it applies regardless of the remote host. Do you happen to know of a suitable place to log an issue for them? I'm not sure they are on GitHub, so perhaps User Voice?

That said, the License Picker is a GH thing, so it would be interesting to see how they would go about evaluating this feature.

Otherwise, the idea of a GitHub pane sounds promising.

[shana]

@tonysneed Actually, I disagree, adding a license is totally a GitHub thing :smile:

The git support in VS (and git in general) is meant to support the process of managing the source control technical aspects of your work, and not what type of content actually goes into the source control. We have a license picker precisely because GitHub goes beyond the mere hosting of git repositories to add tools and processes that help people manage their projects, which is precisely where the license issue comes in.

The problem here is that right now we don't have a good GitHub-specific centralized area in VS for managing those bits of information of your project. All of the areas that we've been talking about are focused on very specific actions (publishing a repo), or are merely informational (the team explorer home page), or are very source-control-specific (the changes tab), so it's hard to put this in a good place that users can find and use.

[tonysneed]

The git support in VS (and git in general) is meant to support the process of managing the source control technical aspects of your work, and not what type of content actually goes into the source control. We have a license picker precisely because GitHub goes beyond the mere hosting of git repositories to add tools and processes that help people manage their projects, which is precisely where the license issue comes in.

@shana Rock on!

The problem here is that right now we don't have a good GitHub-specific centralized area in VS for managing those bits of information of your project.

Is there a possibility of this coming in the future?

[shana]

Is there a possibility of this coming in the future?

It's possible this might start taking shape with the PR feature - see #20

[tonysneed]

I like what I see in #20. Good for GHfVS to get parity with VSTS on PR support.

On an (un-)related note, is there a GH extension for VS Code in the works?