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: Thu, 02 Apr 2015 17:52:11 +0300 Message-ID: <83h9syr3ac.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1427986358 26183 80.91.229.3 (2 Apr 2015 14:52:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Apr 2015 14:52:38 +0000 (UTC) Cc: schwab@suse.de, stephen@xemacs.org, hanche@math.ntnu.no, rms@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 02 16:52:29 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 1YdgTs-00038D-L5 for ged-emacs-devel@m.gmane.org; Thu, 02 Apr 2015 16:52:28 +0200 Original-Received: from localhost ([::1]:58765 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdgTs-0004al-0Z for ged-emacs-devel@m.gmane.org; Thu, 02 Apr 2015 10:52:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59078) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdgTn-0004aT-UE for emacs-devel@gnu.org; Thu, 02 Apr 2015 10:52:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdgTk-0004Dt-Kq for emacs-devel@gnu.org; Thu, 02 Apr 2015 10:52:23 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:44551) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdgTk-0004Dl-7f; Thu, 02 Apr 2015 10:52:20 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NM600C00P35P400@a-mtaout23.012.net.il>; Thu, 02 Apr 2015 17:52:18 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NM600CRKPB5MG50@a-mtaout23.012.net.il>; Thu, 02 Apr 2015 17:52:18 +0300 (IDT) In-reply-to: <20150401123241.GB2633@acm.fritz.box> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:184784 Archived-At: > Date: Wed, 1 Apr 2015 12:32:41 +0000 > From: Alan Mackenzie > Cc: Andreas Schwab , Harald Hanche-Olsen , > rms@gnu.org, emacs-devel@gnu.org > > I do not constrain my git pulls exclusively to the times when I'm > ready to make a sensible commit. May I ask why do you pull (a.k.a. "merge from master") at all while working on a feature? Also, are we talking about you working on a feature branch, or about working directly on master? Generally, work that takes more than, say, an hour or two, and is expected to involve a non-trivial amount of changes, is better done on a separate branch, which you then merge onto master when you are done. While working on such a branch, it makes little sense to merge from master, because that just brings unrelated changes that could potentially disrupt your development. Instead, wait until you are finished with your changes, and then merge. If you do that, then the potential conflicts due to pull/merge from master simply cannot happen. IOW, while working on a feature branch, you commit when you have finished some well-defined part of the job, preferably something that can be, and have been, unit-tested. You then commit something that you know has been tested and was proved to work. Commit log messages in this arrangement describe your advance. Here's an example: the first 10 commits from one of my past feature branches (produced by "git log --oneline"): a12d75c Added initial version of biditest.el and Unicode data file it needs. 2f3daa5 Optimize memory footprint of the bidi level stack. a7fed5a Added BidiBrackets.txt and related Unicode properties to unidqata-gen.el. 2fca7ae Fixed problems revealed by -Wall. 23dbf47 Updated bidi_resolve_weak. Removed next_en_* members from stack. 991b257 Updated pushing and popping the bidi stack, and sos calculations. Added the necessary members to bidi_stack. 5d84f5d Fix find_first_strong_char and implement Unicode 8.0 isolate corrections. d9abb28 Finished coding of explicit directional format characters. 8ccc6fa Remove bidi_ignore_explicit_marks_for_paragraph_level. 4f6bc3c Started working on implementing UBA v6.3. If, OTOH, you are working directly on master, it makes no sense IMO to make intermediate commits, except in some rare situations (like you are off-line for some reason), because if you feel the need to do that, it's a clear sign that you should have done this on a branch. So assuming you DTRT and only do short one-off jobs in master, you can either commit right before you pull from upstream, or do the opposite: pull, then commit. (Both alternatives can run into conflicts, but that's inevitable.) Then you push, and that's it. > > > Then I'd have the hassle of somehow ensuring these silly commits > > > wouldn't find their way back to savannah. > > > There are plenty of options for this. > > Of course there are. I want to avoid the hassle of them; the hassle of > having to write down coherently one or more of these options; the hassle > of having to remember each time to do one of them; the hassle of having > to look up my notes each time. I see no reasons for making "silly commits". IMO, a commit should have a good reason, and "I need to pull" is not one of them. > > > > But that's a trivial deduction from the general theorem: it is a bad > > > > idea to do a lot of work without committing. > > > > Why? > > > Because the only advantage to *not* committing is avoiding the two > > minutes it takes to ask how to accomplish the task of "somehow > > ensuring these silly commits wouldn't find their way back to > > savannah", and learning how to type "git pull --rebase". That would > > mean you have at least two copies of all current work (one in the > > working tree and one in .git/objects), and can easily back up to > > another host with "git push". > > That's a disappointing answer, largely negative. I was hoping for some > new insight into the advantages of frequent committing. I gave some above and in my other messages. Basically, I disagree with what Stephen says above: a commit should generally be a more-or-less complete unit of work, preferably something that can be tested. At least as a rule. That said, as Stephen points out, the tools allow you to commit at any time for a very small price: you need to come up with one line describing the changes in the commit. So if for some reason you need to make a break in your work, and would like to record what you've accomplished, feel free to commit. (Once again, this is much better done on a feature branch than on master.) I don't feel ashamed to have all my intermediate commits with their logs on the project's DAG after the merge; if anything, this forces me to think for a few seconds before I write the log messages. (People who prefer rebasing will probably disagree.) > > Of course, you and Richard want git (and in his case vc.el) to default > > to supporting your workflows, but that's not going to happen, at least > > for git. git is a very flexible tool for supporting a variety of > > workflows, and not only are the workflows that involve "commit early > > and often" already popular, they're gaining. > > Git should support how ever often a developper wants to commit, whether > every 5 minutes or just once per fix. It does. > > 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. That's fine; I do that, too. But still work on a non-trivial feature or fix involves numerous steps and phases, which are usually coded and unit-tested separately. Committing after every such step is IMO good practice, and supports your methodology, I think. I don't quite understand the "dirty linen" part. When you have developed and tested a part of a feature, it might leave Emacs with known bugs elsewhere, since your work is incomplete. But if part of that work is complete and tested, where's the "dirty linen" here? what is there to be ashamed of? > > In CVS and other centralized VCSes, a check-in (to the public > > repository, using Richard's felicitous terminology) is the only way to > > commit, which makes it a very heavyweight operation indeed. Even if > > you have a very good connection to the server, it's still socially > > heavy because the whole project shares it thereafter. > > > In DVCS, check-in is not the only way to commit: just committing and > > waiting to push at an appropriate time is available. This means that > > the social weight of a check-in is no longer an issue. > > CVS's commit is equivalent to git's push, not its commit. The social > weight of git push is the same as cvs commit. Right, but we are not talking about pushing, do we? We are talking about _local_ commits that are not pushed to a public repository, until after you are done with the feature and have merged it to master. > > 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. That's okay; people are generally divided into two camps: those who want to clean up their local commit mess before they make it public, and those who don't make a mess to begin with, at least not a mess they will feel ashamed about. You seem to belong to the second group (so do I); there's nothing wrong about that. It just means you won't use the tools mentioned by Stephen too much. (You will still need some of them to fix stupid errors done on master, like forgetting to commit a file, or committing a change you didn't want to, if you catch them before pushing.) But it still makes sense to make local commits on a feature branch once some unit of your work is completed. > It seems the real answer is "everybody" commits often, so it must be good > thing to do. I've never found that sort of reasoning persuasive. No, that's not the real answer. It could be the popular answer, but there are good reasons to do that; I've mentioned some.