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: Stash Date: Wed, 08 Apr 2015 04:51:24 +0900 Message-ID: <878ue3g1j7.fsf@uwakimon.sk.tsukuba.ac.jp> References: <86sice77h0.fsf@dod.no> <83iod9lnp0.fsf@gnu.org> <83a8yjj348.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1428436327 15868 80.91.229.3 (7 Apr 2015 19:52:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Apr 2015 19:52:07 +0000 (UTC) Cc: sb@dod.no, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 07 21:51:52 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 1YfZXK-0007Ls-1O for ged-emacs-devel@m.gmane.org; Tue, 07 Apr 2015 21:51:50 +0200 Original-Received: from localhost ([::1]:48549 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfZXJ-000184-5U for ged-emacs-devel@m.gmane.org; Tue, 07 Apr 2015 15:51:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfZX6-00017v-Ra for emacs-devel@gnu.org; Tue, 07 Apr 2015 15:51:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YfZX6-00026p-0r for emacs-devel@gnu.org; Tue, 07 Apr 2015 15:51:36 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:39452) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfZX2-00024m-7N; Tue, 07 Apr 2015 15:51:32 -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 47BF81C3856; Wed, 8 Apr 2015 04:51:24 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 245C3120EC9; Wed, 8 Apr 2015 04:51:24 +0900 (JST) In-Reply-To: <83a8yjj348.fsf@gnu.org> 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:185107 Archived-At: Eli Zaretskii writes: > > People said that git merge can fail for another reason (I forget > > what), not only because of conflicts. > > I'm not aware of any, unless they meant uncommitted changes in the > same files that were changed upstream (which is covered on the Wiki > under "conflicts"). Assuming enough free disk and memory, etc, a requested merge that does not terminate normally is always due to conflicts. If the conflict is between the incoming branch and content committed to the current branch, then the merge will be started and terminate with files updated and conflict markers where needed. In git, unlike bzr and hg and "CVS update", normal termination of a merge will also create a commit object and advance the branch's HEAD pointer. If the conflict is between the incoming branch and uncommitted changes in the workspace, the requested merge fails git's preconditions and does not even start. No files in the workspace are touched, no commit objects are created, and the HEAD pointer is not moved. Some people (who I believe are not native speakers) have called both non-success modes "failure".