From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mike Gerwitz Newsgroups: gmane.emacs.devel Subject: Re: VC mode and git Date: Tue, 31 Mar 2015 01:12:47 -0400 Message-ID: <87vbhhpx68.fsf@gnu.org> References: <86egoeusg2.fsf@example.com> <87384qzxqy.fsf@igel.home> <83bnjen71r.fsf@gnu.org> <871tk6538w.fsf@gnu.org> <838ueezgyk.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1427778816 26811 80.91.229.3 (31 Mar 2015 05:13:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 Mar 2015 05:13:36 +0000 (UTC) Cc: sva-news@mygooglest.com, schwab@suse.de, rms@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 31 07:13:28 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 1YcoUN-0005Ie-CL for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 07:13:23 +0200 Original-Received: from localhost ([::1]:36904 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcoUM-0007x2-6r for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 01:13:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcoU9-0007wh-LS for emacs-devel@gnu.org; Tue, 31 Mar 2015 01:13:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcoU6-0001qg-B4 for emacs-devel@gnu.org; Tue, 31 Mar 2015 01:13:09 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36064) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcoU6-0001qc-83 for emacs-devel@gnu.org; Tue, 31 Mar 2015 01:13:06 -0400 Original-Received: from cpe-69-204-47-184.buffalo.res.rr.com ([69.204.47.184]:57834 helo=mikegerwitz-pc.gerwitz.local.gnu.org) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1YcoTy-0007Od-6p; Tue, 31 Mar 2015 01:12:58 -0400 In-Reply-To: <838ueezgyk.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 30 Mar 2015 17:40:35 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:184586 Archived-At: =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Mar 30, 2015 at 17:40:35 +0300, Eli Zaretskii wrote: >> If a push fails, that does not necessarily indicate a "bad state"---it >> simply represents that your history is different than what the remote >> server has, and that the tip of the branch you are pushing to cannot >> simply be "fast-forwarded" to your commit. > > It is "bad" from the POV of someone who started with uncommitted > changes, and ended with them committed locally, but not pushed > upstream. IOW, the command did half the work, and now the user needs > to use commands she might consider "advanced" to fix that. I intended to convey that recovery was easy and that it could be easily rolled back as if commit+push were atomic; there's no need to worry, =2D From a scripting perspective, that a push has failed, because such a thing isn't "bad" in Git. > We decided some time ago that we don't want to rebase, but to pull > instead. It is a pull---`git pull` is simply `git fetch && git merge remote`; its =2D --rebase option uses `rebase` instead of `merge`. Regardless, my apologies---I have only had time to read about 1/3 of the discussion; this is a rather large thread going on. > First, no one suggested any automation here. "C-x v v" is a command > that is invoked by the user, it doesn't invoke itself. It could also > show a warning and ask for confirmation in dubious situations. The thread I responded to was about a hook, which is a script. > And second, with VCSes as versatile as Git (and assuming that people > who use Git in such workflows will at all want to use VC, an > assumption that proved questionable in this discussion), VC should > offer to customize its "next action" decisions so as to adapt them to > a particular workflow. Yes, that's fine; I suggested that. But Richard wanted commit+push as an atomic operation, so only a subset of the commands I provided will be part of any sort of decision tree. I'm not arguing for or against it. I personally do not like the idea of commit+push as an atomic operation, and would rather see VC treat them separately, but that's not what I was providing my input on. =2D --=20 Mike Gerwitz Free Software Hacker | GNU Maintainer http://mikegerwitz.com FSF Member #5804 | GPG Key ID: 0x8EE30EAB =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVGizQAAoJEPIruBWO4w6rnI4QAKrGlbIhr+nqEUC6IOf1QNbE kzuuDVwJC0Yt5kMbeN3cyChd8kp1zn/2iz2CaKgqm6muvMdVZ0elgqFKYhY7P/sw E34YAaexLY1Xz4YfV5WCoR4S5WuQQ+JpxtQZYrlXdMnW7UFeFdzIbtEP45s8WoU6 DWx/R72uYOU5SICex8Hwsa+CkP7EDJ8hvj3VNbVb2/7bSx8qkBkb3s5P+gkC31tp eG45R3HbFhchZ5HoAFTKLP3qDl/DoWocWv+6vUdBmVaqSUgwzYYGaGIdIPSoxVUP DfOxPhLhrLNczZEiZZh07vfqMFlNk2Rhxtt/UmHEJgnteQtsNVmXgVI02y/l1mYP bFJjL49LIieLphwmGoj3xXj8ZJZR1wqHuqjplLTcVsmlFPml7llf9bIs3kKmuZkc NfaV4xZgtpnuTnFRa2slfTFlXs6hdGweMeBFokcldbzD/MTTAV1TQ7i9h7KBnI5l RcTr8BfVgeDsKTMfcT1N2PJrMi69mDrcY1I6aB5CkW4B3tdq2damp0wCItYjZlPY DaCgJ3VqAYyt7EznPwhfJEP54r5hJuqPPdX0rL97ojD+IOaDsdvKg4lgCMPKjO9v VMkL5zqD4kl3YnDnXJ09bt2PtxoZRQxWwPAqOgcYkOb3IAajNEX23lWZiBtOuxR1 wkrasN3XLJ/FvpVMc6PE =3Dgo3H =2D----END PGP SIGNATURE-----