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: VC mode and git Date: Sun, 05 Apr 2015 22:16:18 +0300 Message-ID: <83r3ryl725.fsf@gnu.org> References: <5511998E.8080309@cs.ucla.edu> <5512F8C7.7010509@math.ntnu.no> <5513F889.4000404@math.ntnu.no> <55212DE9.8070806@math.ntnu.no> <83pp7in301.fsf@gnu.org> <87egnyfl5u.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1428261407 14097 80.91.229.3 (5 Apr 2015 19:16:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Apr 2015 19:16:47 +0000 (UTC) Cc: eggert@cs.ucla.edu, hanche@math.ntnu.no, rms@gnu.org, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 05 21:16:41 2015 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 1Yeq2B-0007O5-Qt for ged-emacs-devel@m.gmane.org; Sun, 05 Apr 2015 21:16:39 +0200 Original-Received: from localhost ([::1]:37380 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yeq2A-0000lY-S4 for ged-emacs-devel@m.gmane.org; Sun, 05 Apr 2015 15:16:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49018) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yeq1x-0000lT-22 for emacs-devel@gnu.org; Sun, 05 Apr 2015 15:16:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yeq1o-000645-Vo for emacs-devel@gnu.org; Sun, 05 Apr 2015 15:16:24 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:59774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yeq1o-00063s-O1; Sun, 05 Apr 2015 15:16:16 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NMC00I00KYCKI00@mtaout25.012.net.il>; Sun, 05 Apr 2015 22:11:36 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMC00FH4LBBRE30@mtaout25.012.net.il>; Sun, 05 Apr 2015 22:11:36 +0300 (IDT) In-reply-to: <87egnyfl5u.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.181 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:184970 Archived-At: > From: "Stephen J. Turnbull" > Cc: Harald Hanche-Olsen , > eggert@cs.ucla.edu, > rms@gnu.org, > emacs-devel@gnu.org > Date: Mon, 06 Apr 2015 04:08:13 +0900 > > > It also requires to use at least one more command ("git merge"), > > You can pull from a branch in the same repo. As far as I know, > > git pull . other > > is the same as > > git merge other There's also "git checkout", and maybe a few more. I agree that separate long-lived changes are better kept in separate branches, but we have seen several people who are familiar with Git make silly mistakes that involved two branches, so I'm not sure we should suggest separate branches to people who want to be as close to CVS as possible. > > and brings additional risks, like if you pull to or push from the > > wrong branch. > > It should be possible to use "git config" to set up per-branch > defaults that are correct. > > I was going to suggest this workflow. The problem in Richard's > workflow is that he probably expects that when he's working > simultaneously in different modules (some changes being coded, others > being beta-tested), he should be able to tweak them more or less > independently. But then he'd need to make small "correction" commits > rather than amending the last commit, and cherrypick (or rebase > --interactive) to master for the push. I imagine he'd consider that > inconvenient. Probably.