From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.42.224.197 with SMTP id ip5cs201632icb; Tue, 22 Feb 2011 05:15:51 -0800 (PST) Received: by 10.224.80.208 with SMTP id u16mr2152767qak.196.1298380550941; Tue, 22 Feb 2011 05:15:50 -0800 (PST) Return-Path: Received: from rubyforge.org (rubyforge.org [205.234.109.19]) by mx.google.com with ESMTP id a6si12855973qck.146.2011.02.22.05.15.49; Tue, 22 Feb 2011 05:15:49 -0800 (PST) Received-SPF: pass (google.com: domain of sup-devel-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) client-ip=205.234.109.19; Authentication-Results: mx.google.com; spf=pass (google.com: domain of sup-devel-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) smtp.mail=sup-devel-bounces@rubyforge.org Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 1030718582EE; Tue, 22 Feb 2011 08:15:47 -0500 (EST) Received: from ping.pong.ch (ping.pong.ch [77.109.141.101]) by rubyforge.org (Postfix) with ESMTP id C7C5218582EE for ; Tue, 22 Feb 2011 08:15:08 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ping.pong.ch (Postfix) with ESMTP id 8788040CB4B5 for ; Tue, 22 Feb 2011 14:15:03 +0100 (CET) Received: from ping.pong.ch ([127.0.0.1]) by localhost (ping.pong.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pN+akkmG2NAm for ; Tue, 22 Feb 2011 14:15:02 +0100 (CET) Received: from auth sender gaudenz@ping.pong.ch by ping.pong.ch (Postfix) with ESMTPSA id 75F0440CB4B4 for ; Tue, 22 Feb 2011 14:15:02 +0100 (CET) Received: by meteor.durcheinandertal.local (Postfix, from userid 1000) id 37AE5E2E45; Tue, 22 Feb 2011 14:14:42 +0100 (CET) From: Gaudenz Steinlin To: sup-devel In-reply-to: <1298230750-sup-6418@whisper> References: <1298228733-sup-6115@whisper> <1298230750-sup-6418@whisper> Date: Tue, 22 Feb 2011 14:14:38 +0100 Message-Id: <1298379918-sup-5032@meteor.durcheinandertal.local> User-Agent: Sup/git MIME-Version: 1.0 Subject: Re: [sup-devel] Need help applying patches X-BeenThere: sup-devel@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sup developer discussion List-Id: Sup developer discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1809027256==" Sender: sup-devel-bounces@rubyforge.org Errors-To: sup-devel-bounces@rubyforge.org --===============1809027256== Content-Transfer-Encoding: 8bit Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=-1298380482-172686-9909-6147-1-=" --=-1298380482-172686-9909-6147-1-= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 m= e > 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 ~ --=-1298380482-172686-9909-6147-1-= Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iQIVAwUBTWO2ws3PKyWkzVd5AQgcug//TGQzmCFzej9hGOAXJOMBNiwJwRME5VSk 5Ea4Hf0oNgcQNRvhR33NWgLWg5T56gs9JK8lHSxKyILi8C02cms6iOjCEWsdDDq5 RPPdJ3+2q1r7HvZA0IzFefrUqeOeawUjX5aP/8Qu/wNBiS5DWH2hGvui1ekqK3al aA7DMROGr3yPwr8Z2sD9/jQl/3VBA4IVrPEzflZnxKnsONKO3Am1Dwp/92eDqNxj wbpAb7260IAE58de6NahikeE6fZzM4r42kT1NLes05SN7OYlJaJ/PVVLf7wV/ObU SBr6Rpls8wfC1TCSflQtNZAPA46Ek3eSCt/dpqGNNcabx/If2dQKFj74g7+uxFpM UkjyH6Ntra0lDKlWC7jNDjPkoe0Sa0BzPucuUHfUJC+mXEIqH/JT+S7t5EDXfWsg 86NESwasRnxKnh3jTibm7mWrgOUM9KDnwT3yrYzeytfQ8ZPSNCKI7xL4mjG9Mrg+ yOte9XTXlFxNuUWH+26ScxHjiWTyOTFpRFVEhUaAEwuw3i4L82U5Hv43uWe8Neky l9tGGgYeoIL/NvjdohTIBaG/IB8w9vKttdOn2A2LSpFtQ/3DYyRjmoC7jH93jaO5 UVJOfV58Tr2hSg6XUNKbtI3Roj6TfEcy/bB99ylcnSjShwIuyzC82ZohWrXJDHGG trCdz39nhb8= =nmq7 -----END PGP SIGNATURE----- --=-1298380482-172686-9909-6147-1-=-- --===============1809027256== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sup-devel mailing list Sup-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-devel --===============1809027256==--