-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Proposed Process update #34
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
Conversation
Please remove the process-original.md addition. @DougGregor should review this. |
I think I did it right but I'm a complete moron when it comes to git (which is why all my repos have shell scripts). Can you please check and let me know if I did it or I need to do something more. Thanks, -- E
|
@erica 😆 Looks good, but you'll probably need to squash the 2 commits into 1. |
It might be worth having a quick DevPubs/editorial pass on this document. |
Probably a good idea since I already see a few typos: Is it an evolutionary change to the Swift language or Swift standard library public interface? Is it an evolutionary change to the Swift language or to Swift standard library public interface?
|
I honestly have no idea how that is done. Any tips would be welcome. -- E
|
@erica You should read this, http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html but in essence:
|
I don't think I can be trusted with git. |
I have deleted my fork. And re-submitted a separate pull request. |
FWIW, I have a hard time believing that anyone is a bigger git-moron than me. :-) -Chris |
@erica allow me to humbly suggest that if you're not just doing everything via Github web interface, you could give GitUp a try, instead of the confusing command line git commands. GitUp gives you a very visual way to work with your local copy of the repository. It uses some idioms and enables some actions that are not native to git, but they make a lot of sense:
I need to warn though that this causes what is referred to as changing history, and it has nasty consequences if the commit in question is already merged or somebody else is basing work on top of it. As long as you're always creating a new separate branch on your fork for each single proposed change this should not be a problem (if you propose a change via Github, this is usually done automatically with After you start proposing a change via Github web interface, if you add your fork as a remote to your locally cloned repo, you'll be able to pull and push to the newly created branch by Github. So when somebody asks to rebase or change something, you don't need to create a new branch or redo the work: just make the changes locally and force push. I hope I made myself clear enough, I'm sorry if I didn't 😉 |
I found the original process.md document hard to follow. Here's a proposal for a more readable version.