On 06/02/2014 11:57 AM, Martin Packman wrote: > On 02/06/2014, roger peppe <[email protected]> wrote: >> >> 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?) > > Generally, try to rebase to tidiness before proposing, and not > afterwards. That may mean multiple commits where review comments need > addressing, we may need to discuss as a team how we feel about that. > The commit message(s) come from the revisions in the branch proposed, > so those do want to be nicely formatted before doing the pull request. >
I agree. Rebases rewrite history. You shouldn't be allowed to rewrite history once it becomes a shared history -- including pull requests. Only use rebase for your own private branches, to track upstream. I think the landing bot should squash merge the proposed branch on approval. There's value in keeping a full record of the changes from 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? > > I have a few migration tips to send to the list, but for general > workflow conversion we probably want to try it out and share the pain > and learning together. > > Martin > -Casey
signature.asc
Description: OpenPGP digital signature
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
