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: Tue, 31 Mar 2015 18:24:46 +0900 Message-ID: <87zj6tiko1.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83bnjen71r.fsf@gnu.org> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1427793912 32513 80.91.229.3 (31 Mar 2015 09:25:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 Mar 2015 09:25:12 +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 Tue Mar 31 11:25:02 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 1YcsPp-0006Ds-9x for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 11:24:57 +0200 Original-Received: from localhost ([::1]:37681 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcsPo-0002jt-9r for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 05:24:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcsPl-0002jl-GK for emacs-devel@gnu.org; Tue, 31 Mar 2015 05:24:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcsPi-0003p5-5J for emacs-devel@gnu.org; Tue, 31 Mar 2015 05:24:53 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:45229) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcsPh-0003oA-S6; Tue, 31 Mar 2015 05:24:50 -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 3AF091C3826; Tue, 31 Mar 2015 18:24:47 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 1FDDE120EC9; Tue, 31 Mar 2015 18:24:47 +0900 (JST) In-Reply-To: <20150331085055.GA2871@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:184598 Archived-At: 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). 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. Footnotes: [1] There are slight differences in algorithms, but they mostly don't make a difference -- you'll get the same result.