From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Qainm-00048o-Bm for garchives@archives.gentoo.org; Sun, 26 Jun 2011 06:26:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B3CD51C0A6; Sun, 26 Jun 2011 06:26:17 +0000 (UTC) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.43]) by pigeon.gentoo.org (Postfix) with ESMTP id 75E591C0A6 for ; Sun, 26 Jun 2011 06:26:17 +0000 (UTC) Received: from [85.179.7.97] (helo=[192.168.1.2]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QainQ-0006sJ-DA for gentoo-catalyst@lists.gentoo.org; Sun, 26 Jun 2011 08:26:16 +0200 Message-ID: <4E06D105.6070508@gentoo.org> Date: Sun, 26 Jun 2011 08:26:13 +0200 From: Sebastian Pipping User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110526 Thunderbird/3.1.10 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-catalyst@lists.gentoo.org Reply-to: gentoo-catalyst@lists.gentoo.org MIME-Version: 1.0 To: gentoo-catalyst@lists.gentoo.org Subject: Re: [gentoo-catalyst] master rebase of catalyst 2 References: <20110626050301.GD6710@linux1> In-Reply-To: <20110626050301.GD6710@linux1> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Df-Sender: sping-gentoo@binera.de X-Archives-Salt: X-Archives-Hash: a3131f0f631153cbdbf35b9bfb24ee2b On 06/26/2011 07:03 AM, William Hubbs wrote: > All, > > I checked out a local branch from master earlier today and rebased that > on catalyst_2. Now that branch has over 100 commits, which will be the > combination of everything on catilyst 2 and current master. > > So, how would you suggest we get that branch back out where everyone can > see it? Do you want me to put it back out on master? It won't be a > forced update, because I used rebase instead of merge. > > The only catch is I don't know how broken that will leave master. That sentence^^^ rings at least warning bells in my ears. I don't know how well you know the code, how easy conflicts were to solve. What may be important is that we have little (if any) test cases and that we get little help from Python and Bash to detect breakage for us. If that transition adds a pile of bugs that we'll find by chance somewhere next year, that would be a problem. Personally I may have chosen a road moving both branches towards each other until their diff resolves to zero and than add a fake merge commit. But that's dry theory - no idea if that would have worked well. Plus I woulnd't make it alone and not in a few days or hours. > What are your thoughts? Please put them on a new branch (not master) while we're not sure ff the resulting commits could or should be the future. Thanks, Sebastian