Thanks paul! I couldn't have said it better. You can also see this process
in detail in the forge contributor docs :)
On Tue, May 1, 2012 at 2:16 PM, Paul Bakker <paul.bakker.nl(a)gmail.com>wrote:
First of all, always use a branch to create pull requests, this makes
lot easier to work on several things at a time without getting messy
To fix your current changeset you could create a new branch from master
(without your changes) and re-apply your changes by either "cherry-picking"
them or merging your existing branch into your new branch.
Now squash commits by using interactive rebase (
You should never do this after you pushed to a remote location, but because
this is a new branch it's perfectly fine.
When you're happy with the changeset, push the branch to your github repo,
and create a pull request from that branch. Just close the messy
pull-request, it's probably easier to start clean.
Hope that helps :-)
On May 1, 2012, at 22:12 , Thomas Frühbeck wrote:
> Hi Paul,
> one more question regarding git(hub).
> The situation is the following:
> - I have clone forge core on github
> - have cloned it locally
> - changed some code, committed _and pushed_ into my repository on github
> Is there now any possibility to "remove"/revert/delete/undo this
> _commit_ - not the change itself, just to keep history cleaner when
> sending pull request?
> Help appreciated,
> Am 01.05.2012 13:11, schrieb Paul Bakker:
>> Not in GitHub, but you should squash changesets with git before
creating a pull request.
> forge-dev mailing list
forge-dev mailing list