From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Git mirror - bidrectional Date: Thu, 14 Jan 2010 01:52:37 +0900 Message-ID: <87wrzm0wx6.fsf@uwakimon.sk.tsukuba.ac.jp> References: <877hs6bavz.fsf@catnip.gol.com> <2ACCA862-B70E-4D57-AF88-B36E6DF62FE1@gmail.com> <50BB0D44-FCA5-40C1-BDF7-87D1EE77551D@raeburn.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1263401076 30844 80.91.229.12 (13 Jan 2010 16:44:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Jan 2010 16:44:36 +0000 (UTC) Cc: David Reitter , "emacs-devel@gnu.org discussions" To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 13 17:44:29 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.50) id 1NV6KY-00006b-U1 for ged-emacs-devel@m.gmane.org; Wed, 13 Jan 2010 17:44:27 +0100 Original-Received: from localhost ([127.0.0.1]:34609 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NV6KZ-0003bC-KN for ged-emacs-devel@m.gmane.org; Wed, 13 Jan 2010 11:44:27 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NV6KT-0003aF-Gh for emacs-devel@gnu.org; Wed, 13 Jan 2010 11:44:21 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NV6KO-0003XU-48 for emacs-devel@gnu.org; Wed, 13 Jan 2010 11:44:20 -0500 Original-Received: from [199.232.76.173] (port=46884 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NV6KO-0003XP-26 for emacs-devel@gnu.org; Wed, 13 Jan 2010 11:44:16 -0500 Original-Received: from mx20.gnu.org ([199.232.41.8]:8040) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NV6KN-0001co-DR for emacs-devel@gnu.org; Wed, 13 Jan 2010 11:44:15 -0500 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NV6KI-0001AW-VC for emacs-devel@gnu.org; Wed, 13 Jan 2010 11:44:11 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 31F161535A8; Thu, 14 Jan 2010 01:44:00 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B5CE11A2C00; Thu, 14 Jan 2010 01:52:37 +0900 (JST) In-Reply-To: <50BB0D44-FCA5-40C1-BDF7-87D1EE77551D@raeburn.org> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" 1444e28f1a3d XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:119922 Archived-At: Ken Raeburn writes: > Does git have sufficient hooks to push back submitted changes to bzr > in real time, Probably. There have been some more or less feeble attempts to create bound branches in git with the post-commit hook. That might be usable. There is also a post-update hook for push (see "git help receive-pack"). > and detect conflicts at that point, Any conflicts in pushing to the bzr mainline will be detected by bzr, before anything gets pushed to bzr. But to get to that point, the merge needs to have succeeded in the git mirror. > and report an error to the client without updating the git mirror > (aside from maybe some new commits unreferenced by branch labels)? I think that would you would need is two refs per branch, one public and one for the use of the mirror only. Maybe even three (a public read-only branch updated by the bzr->git process, a public write-only branch whose only reader should be the git-bzr branch, and a private ref used for locking as below). (Note that something like this three-branch method is how git remotes are currently implemented. But at this point I'm to tired to work out whether it would be an improvement in any of the failure states.) To update bzr, the git/bzr repo's post-update hook will 1. Use "git branch -m public private" to lock the branch. (Yes, we want readers locked out too, or you have a rebase fiasco when the bzr push fails.) Before doing this, it should be verified that branch -m is atomic, but I can't imagine why the operation would exist if somebody didn't need it to be atomic. 2. Tag the head. 3. Push your new commits from local workspace to private. 4. Push private to the bzr mainline with bzr. 5. Delete the tag. 6. Use "git branch -m private public" to unlock the branch. If 4 fails, you recreate the public branch at the tag, delete the tag and the private branch ref, and inform the user she lost. Now you have to resync the git mirror with bzr. If 3 fails, you need to update local and try again. First clean up by recreating the public branch ref at the tag, delete the tag and private branch ref. If 1 fails, somebody else is updating, wait your turn. 2, 5, and 6 shouldn't fail unless git is buggy. I think that should work, except that if 4 fails, resyncing to bzr looks like it will need manual intervention. It might not be that bad if everybody who wants to use one of these implements their own, but running one as a public service would probably be hairy.