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: Sat, 28 Mar 2015 03:35:17 +0900 Message-ID: <87mw2yjnkq.fsf@uwakimon.sk.tsukuba.ac.jp> References: <86egoeusg2.fsf@example.com> <83pp7yp5po.fsf@gnu.org> <5511BB2A.2070909@dancol.org> <83619potuw.fsf@gnu.org> <83619nogfq.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 1427481352 2668 80.91.229.3 (27 Mar 2015 18:35:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Mar 2015 18:35:52 +0000 (UTC) Cc: sva-news@mygooglest.com, Eli Zaretskii , dancol@dancol.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 27 19:35: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 1YbZ6U-0006GW-5O for ged-emacs-devel@m.gmane.org; Fri, 27 Mar 2015 19:35:34 +0100 Original-Received: from localhost ([::1]:51308 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbZ6T-00038X-EP for ged-emacs-devel@m.gmane.org; Fri, 27 Mar 2015 14:35:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbZ6N-00038J-BK for emacs-devel@gnu.org; Fri, 27 Mar 2015 14:35:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YbZ6M-0007MZ-Ca for emacs-devel@gnu.org; Fri, 27 Mar 2015 14:35:27 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:47878) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbZ6G-0007Hk-QT; Fri, 27 Mar 2015 14:35:21 -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 1C05E1C3860; Sat, 28 Mar 2015 03:35:18 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E814D120EC9; Sat, 28 Mar 2015 03:35:17 +0900 (JST) In-Reply-To: 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:184413 Archived-At: Richard Stallman writes: > > Bazaar allowed a workflow that Git doesn't, that's why you could > > maintain the illusion of a single operation in a bound branch. > > This seems to be a serious flaw in Git. Hardly. Use of bound branches has always been a minority taste. As somebody else commented, I'm surprised you of all people could stand them, because you need to learn a non-default operation (commit --local) to work disconnected. Did you use "bzr commit --local", or did you just not commit, if you're not connected to Savannah? I'm not even sure what the semantics of bzr commit are in a bound branch containing local commits (push all pending? but that's going to be messy if the push fails). > If our recommendations for how to work on Emacs using Git include > the necessary customization, that could be sufficient to solve the > practical problem. You have a practical problem: git behavior is not compatible with the semantics you assign to "commit". I don't see evidence that Emacs has a practical problem, as a very large number of contributors have successfully converted to the documented git workflow for Emacs. A few do complain, but most are just git-haters from the get-go, and the problems reported on this list seem to be one-off, not created by the recommended workflow. > Dmitry Gutov proposed > > git push || git reset HEAD^ > > Does that work reliably? Not in the sense you mean. It has deterministic semantics, but it takes you to the state immediately after the penultimate commit, not the state immediately before the ultimate commit. These can differ, for example if you've git add'ed, git rm'ed, or git mv'ed files in between. There may be other issues that would bother people looking for an atomic commit-and-push operation.