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: Wed, 25 Mar 2015 19:57:04 +0200 Message-ID: <831tkdot8v.fsf@gnu.org> References: <20150324163714.GA27775@thyrsus.com> <83y4mmpb1n.fsf@gnu.org> <20150324173536.GA30608@thyrsus.com> <83twxap92g.fsf@gnu.org> <20150324181936.GA31705@thyrsus.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1427306253 3215 80.91.229.3 (25 Mar 2015 17:57:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Mar 2015 17:57:33 +0000 (UTC) Cc: esr@thyrsus.com, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 25 18:57:25 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 1YapYO-0004vF-SQ for ged-emacs-devel@m.gmane.org; Wed, 25 Mar 2015 18:57:21 +0100 Original-Received: from localhost ([::1]:40591 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YapYO-0001VE-6b for ged-emacs-devel@m.gmane.org; Wed, 25 Mar 2015 13:57:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34826) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YapYK-0001V9-Ji for emacs-devel@gnu.org; Wed, 25 Mar 2015 13:57:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YapYH-0002p5-Pt for emacs-devel@gnu.org; Wed, 25 Mar 2015 13:57:16 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:54680) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YapYH-0002oa-CN; Wed, 25 Mar 2015 13:57:13 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NLS00800479A200@mtaout29.012.net.il>; Wed, 25 Mar 2015 19:54:13 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NLS001V64ECNB60@mtaout29.012.net.il>; Wed, 25 Mar 2015 19:54:13 +0200 (IST) In-reply-to: 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.185 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:184241 Archived-At: > Date: Wed, 25 Mar 2015 10:43:15 -0400 > From: Richard Stallman > CC: eliz@gnu.org, emacs-devel@gnu.org > > > Even when a remote has been declared, git cannot know about any sequence of > > commits whether it's intended to be published to that remote. It might be > > exploratory programming, done with the option to reset to a prior state > > in mind. > > 1. If that's what you want, why do a commit? You can test the modified > files without committing them. Indeed, I generally commit after I tested. But having written and tested a small part of a large feature doesn't yet mean I'm ready to publish it. As a matter of fact, the small part that I've written and tested might not be useful on its own right, or might even break other features. IOW, the tested code is incomplete. So pushing might be inappropriate. But I still want to keep the history of mu changes recorded in the VCS, because if I later find that I introduced a bug, I want to be able to see which change did that. And there are other good reasons to commit frequently without pushing. Such workflows are widely used these days, and we cannot possibly ignore them, even if you or someone else never uses them. Users will not forgive us if we do. > 2. That is rather sophisticated use; a user who might want to do this > would know how to get what he wants. He could set a flag saying > that C-x v v should not push in this repository, or whatever it takes. Yes, pushing should be optional. The question is how exactly to implement the option, and whether "C-x v v" should do anything else before pushing. For example, I always do a "git show" before pushing, to have one last look at what I will push and make sure I didn't miss anything, or made some mistake. Fixing mistakes in local commits is easy; doing that after pushing is much harder (basically impossible, except by another commit/push). So perhaps "C-x v v" after a local commit should do a "git show", and offer to push from there. > In general, the messages opposing this change have presented arguments > that are weak: possible problems for expert git users that have > obvious solutions that would be be easy for an expert git user to use. AFAIR, none of the messages described any expert uses of Git, they all describe very simple and basic workflows, ones that are widely used by everyone. It would be wrong to make "C-x v v" disrupt those workflows.