-
Notifications
You must be signed in to change notification settings - Fork 547
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Git Changesets #4952
base: master
Are you sure you want to change the base?
Git Changesets #4952
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably need to have a standard way of clearly marking a directory under a different license. I'm unsure exactly what legal waffle may or may not be required to correctly state the scope of a particular license.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CC @krlvi
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After some quick research, I found that it's apparently best practise to have a root license (which applies to the whole project) and extra licenses in sub folders of this project (if they should be licensed differently):
- https://softwareengineering.stackexchange.com/questions/264968/can-a-single-github-repository-include-source-code-released-under-multiple-licen
- https://opensource.stackexchange.com/questions/13172/having-one-sub-folder-in-a-github-repo-under-a-different-license-than-the-whole
So, if we go with adding an information about that in the main license file and add the respective "new" licenses in sub folders (if needed), we should be one the safe side, I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @H1ghBre4k3r, I'll take a read through tomorrow and share with the team so we all have a shared understanding.
27cc3b7
to
16e2768
Compare
16e2768
to
e86fc3b
Compare
- Changesets should be able to be worked on by two different users remotely, with ways of merging together two diverged versions of a particular changeset. | ||
- Changesets should have a unique identifier that tools can use to refer to them by. | ||
- Refer to an arbitrary commit by a changeset, without rewriting it. | ||
- Changesets need to be easily GCed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to have some way of clearing up old and unnecessary change sets so we don't end up flooding the ODB
We've had an in person talk and we've decided to change it quite a bit |
In this PR I'm outlining functionality of git changesets. This is by no means in its final state. I just wanted to start pushing my changes onto GitHub so I don't accidentally use a vim binding to replace every character with 0s again 😆 .