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 1RYndK-0005wW-Ov for garchives@archives.gentoo.org; Thu, 08 Dec 2011 23:44:11 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1B25621C0C9; Thu, 8 Dec 2011 23:44:00 +0000 (UTC) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by pigeon.gentoo.org (Postfix) with ESMTP id B2B6C21C0C9 for ; Thu, 8 Dec 2011 23:43:59 +0000 (UTC) Received: from [85.179.18.203] (helo=[192.168.1.2]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1RYnd8-0008Bw-ML for gentoo-catalyst@lists.gentoo.org; Fri, 09 Dec 2011 00:43:58 +0100 Message-ID: <4EE14BB1.8020400@gentoo.org> Date: Fri, 09 Dec 2011 00:43:45 +0100 From: Sebastian Pipping User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111118 Thunderbird/8.0 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] rfc: merging catalyst git branches References: <20110627044433.GA9772@linux1> <20111208194623.GA2416@linux1> <4EE11E9E.4000809@gentoo.org> <20111208214240.GA10360@linux1> In-Reply-To: <20111208214240.GA10360@linux1> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Df-Sender: c3BpbmctZ2VudG9vQGJpbmVyYS5kZQ== X-Archives-Salt: b3fa3b04-d46c-4fcc-99ae-565e5d1c80f0 X-Archives-Hash: 23668e8a37516e38f348878ffa5c21c0 On 12/08/2011 10:42 PM, William Hubbs wrote: >> The cleanest way to do this this in Git may be: >> >> # git checkout master >> # git merge -s theirs catalyst_2 >> >> Haven't tested it though. Just noticed that I mis-read the git-merge man page: "theirs" is an option of the recursive merge strategy. Sorry. > I checked it out with the folks on #git, and they are recommending > that I rename catalyst_2 to master. I was given a series of commands to > do this. > > The down side is that this will cause a forced update, so everyone will > have to re-clone the repository. Actually there is a way to do this *without* the downside that you describe. The trick is to create a fake merge commit using git commit-tree to sort of emulate merge strategy "theirs". The commit to make needs to: - point to catalyst_2^{tree} as its content. - have current catalyst_2 as its *first* parent in order to - indicate where the data actually came from - make commands like "git show HEAD^" descend into the old catalyst_2 branch later as that's the content that matters - have current master as the second parent (so people can keep working without trouble) This time I tested it myself. This is what to do: 1) Make sure your local master and catalyst are *both* up to date. 2) # git checkout master 3) Create and merge a fake merge commit as defined above: # git merge $(git commit-tree catalyst_2^{tree} \ -p catalyst_2 -p master \ <<<"Replace content on master with content from catalyst_2") Again, the *order* of parents matters. 4) Confirm it went fine, e.g. this diff should now be empty: # git diff master catalyst_2 > The target time I am considering for this is Monday, Dec 11, 0:00 utc. > What that means is, everyone needs to have their changes pushed by then, > then I'll make the change and send out an email here once I'm done. > Then, you will have to re-clone your repositories. > > Any comments? Please consider the alternative explained above. What do you think? Best, Sebastian