From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: VC mode and git Date: Mon, 06 Apr 2015 04:08:13 +0900 Message-ID: <87egnyfl5u.fsf@uwakimon.sk.tsukuba.ac.jp> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1428260916 6581 80.91.229.3 (5 Apr 2015 19:08:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Apr 2015 19:08:36 +0000 (UTC) Cc: eggert@cs.ucla.edu, Harald Hanche-Olsen , rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 05 21:08:27 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 1YepuF-0001fH-HA for ged-emacs-devel@m.gmane.org; Sun, 05 Apr 2015 21:08:27 +0200 Original-Received: from localhost ([::1]:37358 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YepuE-0007Vt-9W for ged-emacs-devel@m.gmane.org; Sun, 05 Apr 2015 15:08:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48317) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YepuA-0007Vj-RY for emacs-devel@gnu.org; Sun, 05 Apr 2015 15:08:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yepu9-0003eA-O8 for emacs-devel@gnu.org; Sun, 05 Apr 2015 15:08:22 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:32967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yepu4-0003dW-4r; Sun, 05 Apr 2015 15:08:16 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id CBE6D1C387E; Mon, 6 Apr 2015 04:08:13 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A2864120EC9; Mon, 6 Apr 2015 04:08:13 +0900 (JST) In-Reply-To: <83pp7in301.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:184969 Archived-At: Eli Zaretskii writes: > > From: Harald Hanche-Olsen > > The usual answer to this is to use development branches instead > > of workin directly in the master branch. I think it was decided > > not to recommend these for simple workflows, but I don't think it > > is that much harder, and it is certainly easier than having > > separate repositories. > > 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 may be some technical difference involving a tracking branch in the case of pull). Of course, you may consider that a separate command since pull requires arguments that need not be specified for master in a repo created by git clone. > 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.