From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: What a modern collaboration toolkit looks like Date: Thu, 03 Jan 2008 11:32:48 +0100 Message-ID: <85odc3qjvz.fsf@lola.goethe.zz> References: <20071230122217.3CA84830B9A@snark.thyrsus.com> <20071231130712.GB8641@thyrsus.com> <87y7b96az8.fsf@member.fsf.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199356406 8518 80.91.229.12 (3 Jan 2008 10:33:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Jan 2008 10:33:26 +0000 (UTC) Cc: Tassilo Horn , emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 03 11:33:46 2008 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 1JANOT-0002qZ-Ri for ged-emacs-devel@m.gmane.org; Thu, 03 Jan 2008 11:33:46 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JANO7-0005q3-J9 for ged-emacs-devel@m.gmane.org; Thu, 03 Jan 2008 05:33:23 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JANMl-0004au-8O for emacs-devel@gnu.org; Thu, 03 Jan 2008 05:31:59 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JANMk-0004ZT-Io for emacs-devel@gnu.org; Thu, 03 Jan 2008 05:31:58 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JANMk-0004ZF-09 for emacs-devel@gnu.org; Thu, 03 Jan 2008 05:31:58 -0500 Original-Received: from mail-in-12.arcor-online.net ([151.189.21.52]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JANMg-0000MF-18; Thu, 03 Jan 2008 05:31:54 -0500 Original-Received: from mail-in-09-z2.arcor-online.net (mail-in-09-z2.arcor-online.net [151.189.8.21]) by mail-in-12.arcor-online.net (Postfix) with ESMTP id 538B44C3CC; Thu, 3 Jan 2008 11:31:52 +0100 (CET) Original-Received: from mail-in-04.arcor-online.net (mail-in-04.arcor-online.net [151.189.21.44]) by mail-in-09-z2.arcor-online.net (Postfix) with ESMTP id 323CB28EDD0; Thu, 3 Jan 2008 11:31:52 +0100 (CET) Original-Received: from lola.goethe.zz (dslb-084-061-012-006.pools.arcor-ip.net [84.61.12.6]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 0FD621BF3D6; Thu, 3 Jan 2008 11:31:52 +0100 (CET) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id EB0EA1CAF1C6; Thu, 3 Jan 2008 11:32:48 +0100 (CET) In-Reply-To: (Richard Stallman's message of "Thu, 03 Jan 2008 04:50:53 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) X-Virus-Scanned: ClamAV 0.91.2/5348/Thu Jan 3 06:26:56 2008 on mail-in-04.arcor-online.net X-Virus-Status: Clean X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:85990 Archived-At: Richard Stallman writes: > There would be no need to have write access at all. I can alway commit > to my repository (even when I'm offline, a fact that should be a big > plus for Richard) and synching happens whenever something important has > be done and some core dev reviewed it. > > I am having trouble understanding what it _means_ to say that you can > do a "commit" into your own repository. That must be something very > different from a "commit" in CVS terms. Perhaps it is so different that > the two are not comparable at all. No, they are pretty similar, except that everybody has his own private repository. The repositories get synchronized not by commit and checkout (those happen only locally), but by pushing and pulling. These operations are very much optimized to deal with merge conflicts and to figure out what changes were already committed remotely. Apart from "remote tracking branches" which you can set up (but don't need to), the histories of various repositories tend to be different. Before pushing something out (or sending around patches), you will likely "rebase" on the repository your patch is referring to. Rebasing means rewinding the history to a common ancestor, applying all the patches from the remote repository, then reapplying all local patches that are not in the remote repository. Merge conflicts may need to get resolved then. Afterwards, your branch history reads like just your local changes on top of the branch/repo/state you rebased on. One tends to rebase local branches from time to time. For branches which are distributed to others, it is nicer to just merge with other repositories/branches since that saves the others from having to do any rewinds leading to possibly repeated merge resolutions. While you can tell git to keep records of past merge resolutions (so that it will resolve the identical problem automatically the next time), it is nicer not to force this. So basically, commit and checkout (and merges, though with an external source) happen locally. Synchronization with others happens directly between repositories by pushing and pulling, and patch distribution. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum