From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Using Git to manage your Emacs changes Date: Thu, 8 Apr 2010 12:57:01 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1270745954 25895 80.91.229.12 (8 Apr 2010 16:59:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 8 Apr 2010 16:59:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 08 18:59:11 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nzv2p-0001WA-Vk for ged-emacs-devel@m.gmane.org; Thu, 08 Apr 2010 18:59:08 +0200 Original-Received: from localhost ([127.0.0.1]:59459 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nzv2f-0000oy-9w for ged-emacs-devel@m.gmane.org; Thu, 08 Apr 2010 12:57:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nzv2b-0000ol-MC for emacs-devel@gnu.org; Thu, 08 Apr 2010 12:57:17 -0400 Original-Received: from [140.186.70.92] (port=59056 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nzv2Z-0000o6-C9 for emacs-devel@gnu.org; Thu, 08 Apr 2010 12:57:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nzv2X-0003eE-2D for emacs-devel@gnu.org; Thu, 08 Apr 2010 12:57:15 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:34844 helo=raeburn.org) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nzv2P-0003cv-AP for emacs-devel@gnu.org; Thu, 08 Apr 2010 12:57:13 -0400 Original-Received: from squish.raeburn.org (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id o38Gv1nl029853; Thu, 8 Apr 2010 12:57:01 -0400 (EDT) In-Reply-To: X-Mailer: Apple Mail (2.1077) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:123350 Archived-At: On Apr 7, 2010, at 15:23, John Wiegley wrote: > If anyone here is like me and can't stand Bzr's = interface/lack-of-speed due to comfort with Git, there is a *somewhat* = more palatable solution: Thanks! > 1. Install git-bzr (http://github.com/pieter/git-bzr). Make sure it = works by > testing on some very small project from someplace. Is this currently the best version to use? There are other versions at = github, perhaps some are better maintained. > 2. Do a bzr checkout of Emacs. DO NOT use git-bzr to directly = checkout the > Emacs tree. It will take days and days and download over 20G of = data. >=20 > 3. Using git-bzr, point it at your local bzr checkout so it can do a = fully local > translation of the Bzr commits to Git commits. This will take = several hours, > but not hog network bandwidth. > 5. Now here's the tricky part. Move your .git directory from your = git-bzr checkout > over into your Bzr working tree. Yes, we want Bzr and Git to = manage the same > tree. You should be wearing your Depends; this is not for the = faint of heart. These (#2,#3,#5) sound like things that git-bzr could simply be updated = to do this way. Well, maybe not the last step, exactly, but can you = move the bzr info into a git checkout instead? Or, to keep it looking = more like a clean git tree, at the cost of more disk space, bury the bzr = info under .git/ and apply the patches in a separate copy there. (That = would also avoid the need for a clean tree at the start, since you = wouldn't clobber your git working copy.) > 7. Sadly, git-bzr is sufficiently broken that you will not be able to = push your > changes with "git bzr push upstream", as the docs indicate. = Instead, we have > to use "git format-patch" and then turn each patch into a Bzr = commit manually, > which get pushed with "bzr push". Once pushed, "git bzr pull = upstream" reflects > that new commit back in Git: Again, it looks like a straightforward enough, programmatic change that = git-bzr could be fixed to just do it. Kind of a shame about the = rebasing requirement, if someone's got local branches; why is it needed? = Is this process unable to push content or commit info into bzr in a way = that matches the git version? What happens at this point if there's a conflict with newer upstream = changes? (I.e., which command fails? Will your script recover or = blindly charge ahead? Do you need any special commands to keep things = in sync in that case?) Ken=