From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.devel Subject: Re: On the subject of Git, Bazaar, and the future of Emacs development Date: Thu, 28 Mar 2013 14:08:19 +0100 Message-ID: <874nfvfz98.fsf@engster.org> References: <87y5d9p5td.fsf@dex.adm.naquadah.org> <87vc8dtbcb.fsf@lifelogs.com> <871ub1gmdf.fsf@engster.org> <87d2ulovd0.fsf@dex.adm.naquadah.org> <85r4j0h1ww.fsf@member.fsf.org> <85li98h1qx.fsf@member.fsf.org> <87ehf0b3x2.fsf@uwakimon.sk.tsukuba.ac.jp> <87obe3gaem.fsf@engster.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1364476116 11803 80.91.229.3 (28 Mar 2013 13:08:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Mar 2013 13:08:36 +0000 (UTC) Cc: Stephen Leake , "Stephen J. Turnbull" , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 28 14:09:00 2013 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 1ULCZe-0000ag-DC for ged-emacs-devel@m.gmane.org; Thu, 28 Mar 2013 14:08:58 +0100 Original-Received: from localhost ([::1]:49260 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULCZG-0007jZ-8e for ged-emacs-devel@m.gmane.org; Thu, 28 Mar 2013 09:08:34 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43269) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULCZC-0007h5-NL for emacs-devel@gnu.org; Thu, 28 Mar 2013 09:08:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ULCZ7-0000yh-Aq for emacs-devel@gnu.org; Thu, 28 Mar 2013 09:08:30 -0400 Original-Received: from randomsample.de ([83.169.19.17]:40956) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULCZ6-0000yI-Vu for emacs-devel@gnu.org; Thu, 28 Mar 2013 09:08:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=C+/ZVphsyG6XeBJ8xeRAZB/PW+dyO6I3WN5cVHi108w=; b=cjRbOMTHQ72aXwzQkHg6M4w/oefX6LYEE+LVyJKsk7FaLrGMhPtSHo43M42HVLK+TcFu7JdwyHs4ZLRZWmNCUXGRrroM3YDfN1fnsIVdXP//tcPbQDE0Lbmg7MtgLX/h; Original-Received: from dslc-082-082-172-165.pools.arcor-ip.net ([82.82.172.165] helo=spaten) by randomsample.de with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1ULCZ3-0004kO-FB; Thu, 28 Mar 2013 14:08:21 +0100 In-Reply-To: (Stefan Monnier's message of "Thu, 28 Mar 2013 08:35:54 -0400") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3 (gnu/linux) Mail-Followup-To: Stefan Monnier , "Stephen J. Turnbull" , Stephen Leake , emacs-devel@gnu.org X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 83.169.19.17 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:158358 Archived-At: Stefan Monnier writes: >> /--to-emacs <-| ---------------------> >> / ^ | diff|patch >> | | | >> | | | >> CEDET ----trunk| <-| Emacs trunk >> | | >> | | >> \ | diff|patch >> \--from-emacs -| <-------------------- > [...] >> Emacs->CEDET: Now that's tedious. You have to first generate a list of >> commits in Emacs trunk which changed files from CEDET. > > Hmm... Why don't you have a more symmetric setup. I.e. have > a "to-cedet" branch on the Emacs side, where the non-CEDET files are > removed and the CEDET files are renamed appropriately? I have thought of doing a similar setup on the Emacs side. The main problem is that I'd have a huge list of conflicts every time I merge from trunk (for every file that was changed which is not in 'to-cedet'). I could probably script things to resolve those automatically, though. Still, getting the list of commits which change CEDET files is not difficult, aside from taking several minutes to complete (basically bzr log lisp/cedet lisp/emacs-lisp/eieio* ...). The real work is getting the patches to apply upstream, resolve conflicts and not loose track of what you've already merged (although I guess I should just merge more often...). -David