Hi Excerpts from Hamish's message of 2011-02-20 20:55:33 +0100: > Excerpts from Hamish's message of Sun Feb 20 19:19:17 +0000 2011: > I ran into some more issues merging this into next - my usual > cherry-pick method led to the same problems as originally, and led to me > being listed as the committer, but I managed to do a git merge which > preserved the commit messages from Gaudenz (although a couple of mine > appear to be repeated). Cherrypicking has basically the same disadvantages as rebasing as it changes the commit ID. So don't cherry pick commits from one branch (e.g. next) into another branch (e.g. gpgme) if you want to merge that branch back into the branch from which you cherry-picked (e.g. you want to merge gpgme back into next). Also don't rebase a branch as soon as you published it somwhere for other to pull from. > > If there is some better way to do this in future, please tell me. I think the correct thing to do is to rebase your development branches against the branch they will eventually be merged into as long as you did not publish them. Rebasing has the nice effect of not complicating the history to much. If you can't rebase then merge, either merge your feature branch into the target branch and then you are free recreate your feature branch and rebase while you are doing development. Or if your changes are not ready yet for merging, you can also merge the target branch into your feature branch to get the latest changes into your feature branch. For testing and day to day usage I usually create a sepeparate branch based of next and merge all my development branches into this branch. This branch is then never published and frequently recreated if something fails... Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Sup-devel mailing list Sup-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-devel