From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: patch vs. overwrite in bzr Date: Wed, 04 Apr 2012 22:11:43 +0300 Message-ID: <83aa2rcnww.fsf@gnu.org> References: <87k42cwys8.fsf@gnu.org> <87limhuldm.fsf@gnu.org> <871uo7g4j6.fsf@gnu.org> <87iphjhbm8.fsf@wanadoo.es> <87398lgrat.fsf_-_@niu.edu> <871uo5c7r0.fsf@wanadoo.es> <87pqbpj5j3.fsf@altern.org> <87aa2szgig.fsf@gnu.org> <87ehs4yrhz.fsf@gnu.org> <83k41vctyg.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1333566711 14368 80.91.229.3 (4 Apr 2012 19:11:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Apr 2012 19:11:51 +0000 (UTC) Cc: bzg@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 04 21:11:48 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SFVcQ-0004yy-3X for ged-emacs-devel@m.gmane.org; Wed, 04 Apr 2012 21:11:46 +0200 Original-Received: from localhost ([::1]:57761 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFVcP-0007Oo-Aa for ged-emacs-devel@m.gmane.org; Wed, 04 Apr 2012 15:11:45 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFVcM-0007Ob-U2 for emacs-devel@gnu.org; Wed, 04 Apr 2012 15:11:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFVcL-0003qa-0B for emacs-devel@gnu.org; Wed, 04 Apr 2012 15:11:42 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:59993) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFVcI-0003qJ-Jf; Wed, 04 Apr 2012 15:11:38 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M1Y00300YK8AI00@a-mtaout22.012.net.il>; Wed, 04 Apr 2012 22:11:29 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.55.144]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M1Y003DTYN4AW00@a-mtaout22.012.net.il>; Wed, 04 Apr 2012 22:11:29 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:149384 Archived-At: > From: Stefan Monnier > Cc: bzg@gnu.org, emacs-devel@gnu.org > Date: Wed, 04 Apr 2012 14:07:25 -0400 > > IIUC it's just difficult to do it "right" because it's largely > incompatible with the way metadata/history is kept. The best you can > get is good support for two-way sync between identical branches (which is > what we all use, where one of the branch is local to our machine and > the other is on bzr.sv.gnu.org), but as soon as the two branches are > supposed to be different the model breaks down. > > The problem is similar to cherry-picking, but reversed: you want to be > able to get all changes except for a few negative-cherrypicks. E.g, > "pull/merge from the Org branch all changes except for those few ones we > don't want" (and inversely, they want to "pull from the Emacs branch, > except for the file-renamings they did to adapt to their directory > layout"). Would the problem be solved if such cherry-picking weren't needed? That is, if the branches were exactly identical, but kept in two different VCSes? If this would solve the problem, then that's what I'd suggest doing. After all, all those differences sound very minor; e.g., why not rename the files as the other guy does? > Since the currently supported metadata can't be used, the solution ends > up having to be "manual" and can probably work equally well for most > VCS. E.g. keep "tags" on both branches that record the last sync, and > when a new sync is attempted, get the diff since last sync on each > branch (using the tags), apply the patch to the other branch, commit and > update the tags. Did anyone consider using bzr-git as part of this? It doesn't yet support pushing to a git repo, but it does support "dpush", which could be good enough. And, of course, pulling from a git repository is fully supported.