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: Wed, 01 Apr 2015 06:43:20 +0900 Message-ID: <87k2xwj11j.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83twx2xoc8.fsf@gnu.org> <87619hke3u.fsf@uwakimon.sk.tsukuba.ac.jp> <551A3F17.6020903@math.ntnu.no> <20150331085055.GA2871@acm.fritz.box> <87zj6tiko1.fsf@uwakimon.sk.tsukuba.ac.jp> <20150331104935.GB2871@acm.fritz.box> <86ego5cp95.fsf@dod.no> <20150331154839.GE2871@acm.fritz.box> <87pp7phxt1.fsf@uwakimon.sk.tsukuba.ac.jp> <20150331204609.GG2871@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1427838236 23483 80.91.229.3 (31 Mar 2015 21:43:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 Mar 2015 21:43:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 31 23:43:48 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 1Yd3wo-0000yU-PS for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 23:43:47 +0200 Original-Received: from localhost ([::1]:40716 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yd3wn-0004g3-TB for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 17:43:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35782) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yd3wc-0004fv-0F for emacs-devel@gnu.org; Tue, 31 Mar 2015 17:43:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yd3wX-0003ZU-1Y for emacs-devel@gnu.org; Tue, 31 Mar 2015 17:43:33 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:54326) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yd3wW-0003Yg-NX for emacs-devel@gnu.org; Tue, 31 Mar 2015 17:43:28 -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 133B41C38ED; Wed, 1 Apr 2015 06:43:21 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E1C22120EC9; Wed, 1 Apr 2015 06:43:20 +0900 (JST) In-Reply-To: <20150331204609.GG2871@acm.fritz.box> 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:184677 Archived-At: Alan Mackenzie writes: > Irreversable? Any patch operation without conflicts is reversable, and > if there are conflicts, a backup of the original should have been made by > the patch program. In a VCS, backup is spelled C-O-M-M-I-T. Which is exactly what you say you don't want to do. *shrug* > Anyhow, there are lots of irreversable things that happen in a VCS > repository. The act of having committed, or merged, or whatever > cannot, with some exceptions, be reversed. Of course. But I mean irreversible changes to the working tree. > It is documented in the hg page. It says (under merge): "The current > working directory is updated with all changes made in the requested > revision since the last common predecessor revision.". If this doesn't > work when a file in the W.D. has been changed, that looks like a bug, > whether in the code or the documentation. The code won't permit. > > .... and Bazaar requires that you use "bzr merge --force". I really > > don't understand how you can criticize git alone for this. > > Because it's only git that's ever given me problems in this > respect. I don't recall ever having problems with bzr update when > I had uncommitted changes. I use hg in such a way that mergeing is > rarely, if ever, needed. It seems bzr update doesn't have that restriction. I don't know why not, bzr merge does have it. Both are so documented. My experience with hg in XEmacs is that when other developers are active, I need an explicit merge frequently. If bzr and hg don't give you problems but git does, then either your git workflow deviates substantially from the workflows you use with bzr and hg, or you've just been lucky to not get nasty conflicts that are difficult to resolve with bzr and hg. I suspect it's the latter, and the big difference is the projects, not the VCSes. Specifically, I suppose Emacs gets a lot more changes from other developers per unit time than your other projects do. > I do not love risk. The risk of getting my repository in an > inextricable tangle, like Richard has done, far outweighs any > supposed risks of just-in-time committing. Richard's repo is tangled *because* he, like you, doesn't commit until he's ready to push. If you keep your changes in commits instead of the working tree, it's *very* hard to get inextricably tangled in git because a quick reset puts you back in control, in a known state.