From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Harald Hanche-Olsen Newsgroups: gmane.emacs.devel Subject: Re: VC mode and git Date: Fri, 03 Apr 2015 10:34:23 +0200 Message-ID: <551E508F.3060609@math.ntnu.no> References: <87384qzxqy.fsf@igel.home> <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> <551A59F1.3060602@math.ntnu.no> <86384lciin.fsf@dod.no> <86r3s1acxv.fsf@dod.no> <83twwxpsbg.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1428050083 31000 80.91.229.3 (3 Apr 2015 08:34:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Apr 2015 08:34:43 +0000 (UTC) Cc: Steinar Bang , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 03 10:34:42 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 1Ydx3p-0003WM-0I for ged-emacs-devel@m.gmane.org; Fri, 03 Apr 2015 10:34:41 +0200 Original-Received: from localhost ([::1]:33013 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ydx3o-0004Hp-4v for ged-emacs-devel@m.gmane.org; Fri, 03 Apr 2015 04:34:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50725) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ydx3j-0004HX-Sl for emacs-devel@gnu.org; Fri, 03 Apr 2015 04:34:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ydx3j-0001ot-3z for emacs-devel@gnu.org; Fri, 03 Apr 2015 04:34:35 -0400 Original-Received: from hylle05.itea.ntnu.no ([2001:700:300:3::225]:39183) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ydx3h-0001eR-QU; Fri, 03 Apr 2015 04:34:33 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by hylle05.itea.ntnu.no (Postfix) with ESMTP id 57E5690C5C7; Fri, 3 Apr 2015 10:34:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at hylle05.itea.ntnu.no Original-Received: from [IPv6:2001:4662:4ffb::8987:b5a9:4382:3a66] (unknown [IPv6:2001:4662:4ffb:0:8987:b5a9:4382:3a66]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hanche) by hylle05.itea.ntnu.no (Postfix) with ESMTPSA id 9388090C3CE; Fri, 3 Apr 2015 10:34:25 +0200 (CEST) User-Agent: Postbox 3.0.11 (Macintosh/20140602) In-Reply-To: <83twwxpsbg.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:700:300:3::225 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:184820 Archived-At: Eli Zaretskii wrote: > The situation is that a pull was done and failed because of > conflicting local commits. The merge part of the pull in this case is > already aborted. But if so, where are all the modified files in the index coming from? My=20 hypothesis is that they come from the merge. More precisely, I expect=20 they are exact copies from origin/master. > All Richard needs to do is resolve the conflicts one > by one (AFAIU, he only had one to begin with, in a ChangeLog file), > and then do: > > git commit > git push Agreed, though I don't think he should push without doing a sanity check=20 first. Basically, =E2=80=9Cgit diff origin/master=E2=80=9D to check that = he is merely=20 committing his own changes. (I *think* that will be so, but I don't=20 *know* it.) Also, he will need to do another git pull, possibly followed=20 by resolving more conflicts, before being able to push. > So why would Richard need to use "stash" in this situation? It sounds > like an unnecessary complication. Am I missing something? No need for a stash. If the result of fixing the ChangeLog and=20 committing is not what is desired, that can be fixed later. There is no=20 possible information loss from the proposed course of action, apart from=20 in lisp/ChangeLog, and that shouldn't be hard to remedy. =E2=80=93 Harald