From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: What a modern collaboration toolkit looks like Date: Sat, 05 Jan 2008 17:46:15 -0500 Message-ID: References: <20071230122217.3CA84830B9A@snark.thyrsus.com> <20071231130712.GB8641@thyrsus.com> <87y7b96az8.fsf@member.fsf.org> <87fxxfnrhi.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199573230 20474 80.91.229.12 (5 Jan 2008 22:47:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Jan 2008 22:47:10 +0000 (UTC) Cc: tassilo@member.fsf.org, emacs-devel@gnu.org, Miles Bader To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 05 23:47:31 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 1JBHnc-0003p1-87 for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 23:47:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBHnD-0007WP-Js for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 17:47:03 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JBHn9-0007Vi-S4 for emacs-devel@gnu.org; Sat, 05 Jan 2008 17:46:59 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JBHn4-0007VT-Ja for emacs-devel@gnu.org; Sat, 05 Jan 2008 17:46:58 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBHn4-0007VQ-Cv for emacs-devel@gnu.org; Sat, 05 Jan 2008 17:46:54 -0500 Original-Received: from 206-248-175-132.dsl.teksavvy.com ([206.248.175.132] helo=ceviche.home) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JBHmh-00011d-J3; Sat, 05 Jan 2008 17:46:32 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 1734AB40FE; Sat, 5 Jan 2008 17:46:14 -0500 (EST) In-Reply-To: (Richard Stallman's message of "Sat, 05 Jan 2008 00:55:46 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) 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:86249 Archived-At: > So perhaps you hack all day, periodically making commits (using "git > commit") which store your changes into the .git subdir. Then when you > later connect to the net, you can merge the new changes in .git into the > remote emacs repository on savannah (using "git push"). > It sounds like "git push" is the real analogue of CVS commit, > and that this is the closest match-up between the concepts of git > and the concepts of CVS: > CVS GIT > save file = commit > commit = pull or push Kind of, yes, except that the "git commit" really does a "local commit" to a local branch. In VC we implemented a poor-man replacement by allowing mixing various backends, where the expected use was as follows: Let's say you have a file under CVS which you want to modify. The modifications are fairly long running and you feel like you'd want to be able to commit every once in a while so you can go back or so you can diff between various intermediate stages of your work. But as it turns out you don't actually want to commit to the CVS either because the CVS repository is unavailable (offline, or read-only), or because you're not sure you'll want to install the change in the end, or ... So you register your file under RCS: the file is now both under CVS and under RCS at the same time. C-x v b allows you to switch VC's view between the two backends. So now you can do all your local commits to RCS, with ability to do diffs/revert/... without needing to contact the CVS repository. After a while, your hacking may result in something you decide deserves to make it into the CVS, so you go ahead and commit the new file to CVS. VC actually provides you with a command that makes up the changelog for this commit by extracting it from the RCS file, thus basically transfering the local RCS branch to the CVS repository (as a single change rather than a bunch of little changes). In the above context, the equivalence would be: CVS&RCS Git save file save file commit to RCS commit commit to CVS push > But I still don't understand what step actually alters the trunk that > users will get by default from the public repository. Does `push' do > that? Yes, presuming that by "push" you mean "push to the default public repository". Stefan