Well the linked doc said to rebase before propose: When ready for feedback, push your feature branch to github, optionally after collapsing multiple commits into discrete changes:
$ git rebase -i --autosquash master $ git push origin new_feature John =:-> On Mon, Jun 2, 2014 at 3:42 PM, roger peppe <[email protected]> wrote: > On 2 June 2014 11:19, Ian Booth <[email protected]> wrote: > > Hi folks > > > > As per previous communications, we'll be migrating the juju-core > codebase off > > Launchpad and across to Github at 10:00 UTC Tuesday 3 June. > > > > Here's a link to the new Contributing document which describes the new > landing > > workflow: > > > > > https://raw.githubusercontent.com/bz2/core/4a7de7b9a52bab794821766e40503a66ca08fcaa/CONTRIBUTING > > Thanks for this. Two questions come to mind. > > What is the policy around rebasing before commenting with $$merge$$ ? > Does this need to be done? If not, how does the merge procedure > decide what commit message gets attached to the final merge? > (Or are we going to leave one commit message for every > stage in the review?) > > Has anyone put together a bzr->git cheatsheet for those of us still > suffering > from git "*how* many ways to do it?!" overload? > > cheers, > rog. > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
