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 10:49:35 +0000 Message-ID: <20150331104935.GB2871@acm.fritz.box> References: <871tk6538w.fsf@gnu.org> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1427799022 18993 80.91.229.3 (31 Mar 2015 10:50:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 Mar 2015 10:50:22 +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 12:50:14 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 1YctkI-00052r-Bb for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 12:50:10 +0200 Original-Received: from localhost ([::1]:37951 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YctkH-0001xy-Qv for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 06:50:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56039) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yctk1-0001xr-0t for emacs-devel@gnu.org; Tue, 31 Mar 2015 06:49:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yctjx-0004rW-Fk for emacs-devel@gnu.org; Tue, 31 Mar 2015 06:49:52 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:29119 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yctjx-0004rG-6K for emacs-devel@gnu.org; Tue, 31 Mar 2015 06:49:49 -0400 Original-Received: (qmail 64906 invoked by uid 3782); 31 Mar 2015 10:49:46 -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 12:49:45 +0200 Original-Received: (qmail 4322 invoked by uid 1000); 31 Mar 2015 10:49:35 -0000 Content-Disposition: inline In-Reply-To: <87zj6tiko1.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:184600 Archived-At: Hello, Stephen. On Tue, Mar 31, 2015 at 06:24:46PM +0900, Stephen J. Turnbull wrote: > Alan Mackenzie writes: > > That is the case in the current git version. I think that in previous > > versions, git took the liberty of simply overwriting changed files in > > the workspace. > git has never done that, and never will (if it does, there will > immediately be a fork that doesn't and all sane users will switch). I lost some changes in my working directory after doing something like git pull. I can't remember the details any more. I was able to reconstruct the changes without too much difficulty. > git reset --hard will do that, and there may be a --force option to > checkout that will do that. But you have to explicitly request git to > overwrite files that are not in the state that git last committed > them, and as far as I know merge never does that. (There may be > circumstances where it will do a 3-way merge on an uncommitted file, > but normally it will balk, and always has done so AFAICR.) > Note that all VCSes have the equivalent of git reset --hard. > > Why can't git simply merge changes properly into the workspace, thus > > saving users the unwelcome hassle of, e.g., git stash followed by git > > merge followed by git stash pop? > 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. With git pull, if there are changes in the working directory, the merge (i.e. merge from remote/master into master) part of the operation is aborted before it starts, giving a message describing its refusal. It does this even when there are no conflicts to deal with. 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. Part of the problem is that the git-merge man page doesn't say that it messes with the working tree (or, more precisely, it vaguely alludes to it in the small print several hundred pages down). In fact, it doesn't say up front _what_ it is merging, or where the merged result goes - it merely says "Join two or more development histories together", leaving it as an exercise for the reader to figure out exactly what is meant by a "development history". By contrast, hg merge is documented concisely and adequately as "merge another revision into working directory". > Footnotes: > [1] There are slight differences in algorithms, but they mostly don't > make a difference -- you'll get the same result. -- Alan Mackenzie (Nuremberg, Germany).