From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ricardo Wurmus Newsgroups: gmane.emacs.devel Subject: Re: VC mode and git Date: Wed, 01 Apr 2015 21:50:46 +0200 Message-ID: <87619feig9.fsf@mango.localdomain> 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> <87y4mdi7tj.fsf@uwakimon.sk.tsukuba.ac.jp> <20150331214347.GH2871@acm.fritz.box> <87iodgiqr8.fsf@uwakimon.sk.tsukuba.ac.jp> <20150401123241.GB2633@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1427917870 13878 80.91.229.3 (1 Apr 2015 19:51:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Apr 2015 19:51:10 +0000 (UTC) Cc: "Stephen J. Turnbull" , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 01 21:51:03 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 1YdOfH-00039z-0t for ged-emacs-devel@m.gmane.org; Wed, 01 Apr 2015 21:51:03 +0200 Original-Received: from localhost ([::1]:54847 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdOfG-0004Pb-DP for ged-emacs-devel@m.gmane.org; Wed, 01 Apr 2015 15:51:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59890) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdOfC-0004MK-11 for emacs-devel@gnu.org; Wed, 01 Apr 2015 15:50:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdOf7-0004s5-Pj for emacs-devel@gnu.org; Wed, 01 Apr 2015 15:50:57 -0400 Original-Received: from sender1.zohomail.com ([74.201.84.162]:52939) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdOf7-0004rk-Ht for emacs-devel@gnu.org; Wed, 01 Apr 2015 15:50:53 -0400 Original-Received: from localhost (x2f77ff4.dyn.telefonica.de [2.247.127.244]) by mx.zohomail.com with SMTPS id 14279178503251010.7966906177527; Wed, 1 Apr 2015 12:50:50 -0700 (PDT) In-reply-to: <20150401123241.GB2633@acm.fritz.box> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x X-Received-From: 74.201.84.162 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:184756 Archived-At: Alan Mackenzie writes: >> That's because a commit is just a way of delegating a pile of >> record-keeping to the VCS. In particular, it identifies a state of >> development that you or others might want to replicate. > > A commit is a commitment. It is an affirmation, possibly public, of the > value of the new code, to its integrity, it is a declared willingness to > stand up and defend the thing committed to. I do not commit my dirty > linen, which is what people seem to be advocating I should do. [...] >> You can commit on any whim, and git's whole design is to make whimsical >> commits as cheap as possible. Part of that is the much derided staging >> area as well as other aspects of caching the blobs and trees, but part >> of that is "git reset --soft" and the DAG editing capabilities it >> provides. You can throw away commits while keeping the changes using >> interactive rebasing, or do the commits on a branch and merge, or any >> combination that makes sense to you. > > The only combination that makes sense to me is that which involves the > least risk and the least time and effort wasted in ploughing through > git's inadequate documentation. I don't want to spend several hours > learning how to "throw away commits while keeping the changes using > interactive rebasing", or even in learning what that all really means. I > am one of these seemingly rare people who are not fascinated by the > innards of git, and simply want an appropriate tool for communicating > changes from and to savannah. I know I'm not the only one. I think you > have trouble accepting this position. I'm not "fascinated by the innards of git" and I don't find the man pages very useful, but creating commits often and interactively rebasing them before publishing (i.e. "git push") lies at the core of my workflow, and I would not do it if it wasn't easy and convenient. Your concept of a commit as "an affirmation [...] of the value of the new code" does not need to apply to local, "whimsical", cheap commits. Before publishing you can *easily* squash, delete, edit, rename, move commits with interactive rebase. You can defer the decision when something is ready for publication without having to forgo commits (I think of them as "quicksave" in games). Committing often and rebasing for publication are both cheap operations with little mental overhead. It would be insanity for me to keep a dirty working directory with potentially valuable changes uncommitted. ~~ Ricardo