Refining patches using git
Here are some pointers how you can use git to create a clean set of commits for possible inclusion in Erlang/OTP.
If you forgot to add a file to the previous commit, or similar mistakes, or want to edit the commit message, then git commit --amend can help you.
Amend will not create a new commit on top of HEAD, but instead open the last commit, change it and replace it with the new amended commit. This means that you should never amend to a published commit.
Interactively choose hunks of patch between the index and the work tree and add them to the index. This gives the user a chance to review the difference before adding modified contents to the index.
This effectively runs git add --interactive, but bypasses the initial command menu and directly jumps to the patch subcommand. See “Interactive mode” for details.
Interactive rebase allow you to clean up your commit history by:
- removing commits
- splitting commits
- squashing commits (like
git commit --amend) - open up commits for editing
- reword commit messages
See interactive mode for details.
By default, git push will refuse to push a branch that have been amended or rebased, because in general rewriting history will cause problems for anyone that has fetched the original version of the branch and you will lose the previous history of the branch.
When refining patches, however, rewriting history is fine. No one is supposed to base any work on a topic branch before it has been merged to the development branch. To force git push to push anyway, use the -f option:
git push -f origin my-topic-branch
or put a + sign before the name of the branch:
git push origin +my-topic-branch