From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: VC mode and git Date: Tue, 31 Mar 2015 21:43:47 +0000 Message-ID: <20150331214347.GH2871@acm.fritz.box> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1427838295 24482 80.91.229.3 (31 Mar 2015 21:44:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 Mar 2015 21:44:55 +0000 (UTC) Cc: Andreas Schwab , Harald Hanche-Olsen , rms@gnu.org, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 31 23:44:47 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 1Yd3xb-0001ck-RY for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 23:44:36 +0200 Original-Received: from localhost ([::1]:40720 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yd3xa-00056F-TJ for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 17:44:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36123) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yd3xJ-00055u-U6 for emacs-devel@gnu.org; Tue, 31 Mar 2015 17:44:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yd3x4-0003jL-PP for emacs-devel@gnu.org; Tue, 31 Mar 2015 17:44:17 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:50887 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yd3x4-0003j4-Fa for emacs-devel@gnu.org; Tue, 31 Mar 2015 17:44:02 -0400 Original-Received: (qmail 53353 invoked by uid 3782); 31 Mar 2015 21:43:58 -0000 Original-Received: from acm.muc.de (pD9519B17.dip0.t-ipconnect.de [217.81.155.23]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 31 Mar 2015 23:43:56 +0200 Original-Received: (qmail 7127 invoked by uid 1000); 31 Mar 2015 21:43:47 -0000 Content-Disposition: inline In-Reply-To: <87y4mdi7tj.fsf@uwakimon.sk.tsukuba.ac.jp> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.1 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:184678 Archived-At: Hello, Stephen. On Tue, Mar 31, 2015 at 11:02:16PM +0900, Stephen J. Turnbull wrote: > Alan Mackenzie writes: > "Commit early, commit often", and you won't have to worry about > remembering the details of your workflow. And have my repository clogged up with meaningless arbitrary commits with commit messages like "Just before resync with savannah, 2015-03-31 22-58"? Then I'd have the hassle of somehow ensuring these silly commits wouldn't find their way back to savannah. I know vaguely this is a solved problem, but it's one more thankless bit of drudgery I don't want to get involved with. > > > It does, the same way that bzr or Mercurial does.[1] I don't see > > > why you would think otherwise. > > Partly due to the following bug report which is near the start of the > > git-merge man page: "Warning: Running git merge with non-trivial > > uncommitted changes is discouraged: while possible, it may leave you in a > > state that is hard to back out of in the case of a conflict.". I can't > > imagine why the git maintainers don't fix this. > Fix what? One can do it if one wants to. It's usually not dangerous > because merge will abort if there are any local uncommitted changes in > a file that would be changed by the merge. It's actually rather > useful in certain limited use cases, for example when I have a > different ignore file from upstream. In Mercurial, I have a patch in > a queue that handles this but it's PITA to deal with. (Note that > everybody's favorite blunted plastic scissors, aka Bazaar, has a > "merge --force" option to allow the user to make the choice.) > It is indeed a bad idea to do a lot of work without committing and > then merging. Why? > But that's a trivial deduction from the general theorem: it is a bad > idea to do a lot of work without committing. Why? These two "why?"s are not rhetorical questions. [ .... ] > > Mercurial will complete hg pull regardless of any changes in its working > > directory; in the case of conflicts it may leave several heads which > > require merging. > Which is exactly what git does: > b 22:00$ git pull > remote: Counting objects: 3, done. > remote: Compressing objects: 100% (3/3), done. > remote: Total 3 (delta 1), reused 0 (delta 0) > Unpacking objects: 100% (3/3), done. > From /tmp/test/./a > 684eca7..d47c24c master -> origin/master <<<< LOOK LOOK LOOK > Updating 684eca7..d47c24c > error: Your local changes to the following files would be overwritten > by merge: > quuz > Please, commit your changes or stash them before you can merge. > Aborting > I think you're partly confused by the fact that what Mercurial calls > pull is what git calls fetch, and what git calls pull has no > equivalent in core Mercurial AFAIK (pull -u only updates on a fast > forward). No, I'm not confused on this point. There is hg fetch (deprecated) which does hg pull followed (possibly) by hg merge, then hg update, more or less. I've never used it. > > Part of the problem is that the git-merge man page doesn't say that > > it messes with the working tree > What else would it do? Merge tools have changed the working tree from > time immemorial. That's poor, Stephen. It might well merge in the repository without touching the working tree. The fact is, the documentation doesn't say this - it doesn't even say where the two sources for its merge come from, or where it puts the result. > 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? :-) > I find it a PITA that Mercurial doesn't, but rather requires a separate > merge operation and then an explicit commit. > > By contrast, hg merge is documented concisely and adequately as > > "merge another revision into working directory". > Everybody hates git's documentation. I thought you were complaining > about bugs in the program? 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. -- Alan Mackenzie (Nuremberg, Germany).