-
Notifications
You must be signed in to change notification settings - Fork 793
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
Add contributing guidelines to repo root #1
Conversation
+1 looks good to me! |
+1 |
@latkin Why not just merge PR from GitHub UI? Now it looks like a canceled PR =(. |
Yep I was just going to say this. There 2 possible ways:
|
The "merge pull request" button does a no-fast-forward merge, which isn't great IMO... So far we have been doing In this particular case I wanted to move the commit to Is there a better way (besides the merge button) to close the PR so that it looks right? |
I did merge it manually, but I did not see any change to this PR, so I just linked the commit and closed it. git automatically updates the committer whenever you do rebase, etc. |
Why do you prefer each PR as a single commit (just to understand the incentive)? Isn't it better to keep original commits so that we know how features are implemented incrementally? |
I know this one is controversial, but the explicit merge-commit is not a bad thing because it makes the pull request visible in the git history. It allows us to find the discussion and additional information from the history/code. |
regarding rebase and squash; most projects ask the author to clean up the pull request before they accept it. |
I’m afraid it doesn’t work with our current codeflow. We our doing things that will make it possible eventually but right now that workflow doesn’t work for us. Please let’s not boil the ocean, let us get a workflow that works well for us, and we can evolve it over time, as we find improvements that we like. Kevin From: Steffen Forkmann [mailto:[email protected]] I know this one is controversial, but the explicit merge-commit is not a bad thing because it makes the pull request visible in the git history. It allows us to find the discussion and additional information from the history/code. — |
of course. we just trying to understand. |
Merge vs rebase is indeed religious war territory, don't want this to devolve into that. Single commit per PR is not uncommon - see here, here. I think I should have just added "Closes #1" to the message, and that would have done the auto-linkup. Totally agree that it's nice having everything linked up properly. Apologies I didn't figure that our initially, we are still GitHub n00bs. |
A gif. Finally ;-) All is well |
…if-coreclr-enabled fix to build
Adding ListEnumerable, Choose, and some cleanup
Merge from upstream
Introduce TupleTypeSegment to SynType.Tuple.
This PR copies contributing guidelines from the wiki to repo root.
It gives better discoverability for contributing guidelines. Whenever a user opens a new issue/pull request, the contributing guidelines will show up.
See https://github.com/blog/1184-contributing-guidelines.