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: Wed, 01 Apr 2015 10:25:31 +0900 Message-ID: <87iodgiqr8.fsf@uwakimon.sk.tsukuba.ac.jp> References: <838ueezgyk.fsf@gnu.org> <878ueejnjz.fsf@uwakimon.sk.tsukuba.ac.jp> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1427851567 28369 80.91.229.3 (1 Apr 2015 01:26:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Apr 2015 01:26:07 +0000 (UTC) Cc: Andreas Schwab , Harald Hanche-Olsen , rms@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 01 03:25:59 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 1Yd7Pq-0002KE-EQ for ged-emacs-devel@m.gmane.org; Wed, 01 Apr 2015 03:25:58 +0200 Original-Received: from localhost ([::1]:41163 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yd7Pp-0004F1-Ng for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 21:25:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yd7Pb-0004Ew-TT for emacs-devel@gnu.org; Tue, 31 Mar 2015 21:25:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yd7PY-0006YI-IG for emacs-devel@gnu.org; Tue, 31 Mar 2015 21:25:43 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:58447) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yd7PX-0006SP-UJ; Tue, 31 Mar 2015 21:25:40 -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 961101C38DA; Wed, 1 Apr 2015 10:25:31 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 6F2A4120EC9; Wed, 1 Apr 2015 10:25:31 +0900 (JST) In-Reply-To: <20150331214347.GH2871@acm.fritz.box> 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:184682 Archived-At: Alan Mackenzie writes: > And have my repository clogged up with meaningless arbitrary commits with > commit messages like "Just before resync with savannah, 2015-03-31 > 22-58"? I see nothing arbitrary about: 2015-03-31 Alan Mackenzie Development of foobar complete, all tests pass, documentation done. * foobar.el: New file. 2015-04-01 Alan Mackenzie Integration of foobar to trunk complete, all tests pass. * foobar.el (foo, bar, baz): Refactor: use pcase, now that it has decent docs. IMHO, these are specific, well-defined milestones that merit commits. YMMV, but IME these last-minute adjustments to others' changes involve far more than their share of defects, so having a next-to-last commit in the known, comfortable pre-pull context and then one last commit for integration is likely to do far more than its share of bug localization when bisecting. > 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. > > It is indeed a bad idea to do a lot of work without committing and > > then merging. > > Why? See the general theorem. > > 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". 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. 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. 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. 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. When I have achieved a state that deserves publication, I want to save it in a reliable way that doesn't involve me remembering not to touch that workspace, etc. Maybe you don't want to do that, but I assure you the cost of learning to use an appropriate workflow is far lower than the cost of reproducing even a score of lines that disappeared due to a silly typo or a tool whose documentation was unclear. > These two "why?"s are not rhetorical questions. Yes, they are. You (and Richard) don't want to know the answers because acknowledging them would very likely induce changes in your workflows, and everybody else already does know the answers. > No, I'm not confused on [the different usage of merge, fetch, and > pull in git and hg]. Well, the language you use makes it very difficult to determine whether you are or aren't. For example, when you write "merge", it's hard to tell whether you are referring to a particular VCS's designed semantics, to the goal you want to achieve in the workspace, or to the particular command provided by a given VCS. I suspect, but can't say for sure for lack of verbal cues, that you actually switch back and forth from one sentence to the next. > > What else would it do? Merge tools have changed the working tree > > from time immemorial. > > That's poor, Stephen. [...] The fact is, the documentation > doesn't say this I'm sorry, but that point is moot. Emacs chose git despite the well-known deficiencies of its documentation, primarily because there are a lot of Emacs workers who like git and know it fairly well. One now needs to use git to work on Emacs efficiently. So suck it up and use the wetware that has accumulated around you. > > What's different from traditional 3-way merge tools (that aren't > > part of a VCS) is that git *also* creates a commit with more than > > one parent (which is what is meant by joining development > > histories). > > Do development histories have 40-byte hashes? :-) Of course they do. Each commit implies a whole development history through the parents attribute, just as each cons implies a whole list through the cdr attribute. > The documentation is part of the program. Whether bugs are in the > doc or the prog, it costs just as much wasted time and energy. Only because you're unwilling to ask for help. Asking for help from Emacs developers is a very cheap and effective substitute for good docs, and surely you have sufficient standing in the community to warrant attention to your questions. Of course you probably want to choose the advice of someone like Eli rather than somebody like Andreas, but both would undoubtedly answer your questions. Regards,