From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: VC mode and git Date: Wed, 01 Apr 2015 17:43:18 +0300 Message-ID: <83bnj7syd5.fsf@gnu.org> References: <86egoeusg2.fsf@example.com> <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1427899448 24853 80.91.229.3 (1 Apr 2015 14:44:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Apr 2015 14:44:08 +0000 (UTC) Cc: sb@dod.no, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 01 16:43:59 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 1YdJs6-0004zY-Dr for ged-emacs-devel@m.gmane.org; Wed, 01 Apr 2015 16:43:58 +0200 Original-Received: from localhost ([::1]:53063 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdJs5-0007Xh-J4 for ged-emacs-devel@m.gmane.org; Wed, 01 Apr 2015 10:43:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34426) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdJrr-0007Xc-Qm for emacs-devel@gnu.org; Wed, 01 Apr 2015 10:43:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdJrn-0007ud-Nv for emacs-devel@gnu.org; Wed, 01 Apr 2015 10:43:43 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:38352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdJrn-0007uE-GZ; Wed, 01 Apr 2015 10:43:39 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NM400L00U08I600@a-mtaout21.012.net.il>; Wed, 01 Apr 2015 17:43:37 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NM400LNJU8FI110@a-mtaout21.012.net.il>; Wed, 01 Apr 2015 17:43:37 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 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:184717 Archived-At: > Date: Wed, 01 Apr 2015 06:22:15 -0400 > From: Richard Stallman > Cc: emacs-devel@gnu.org > > > > Reportedly pull includes merge, so this implies that git pull is also > > > dangerous when you have made changes. > > > Dangerous in which way? > > I don't know. The git documentation says it can cause some sort of > lossage, but was not specific. I suggest that you disregard that hypothetical lossage. > > If you get a conflict in the merge, git will not complete the commit > > until the conflict is handled (much as any version control system). > > 1. Is that what happened to me? I've sent the output of several > diagnostic commands; perhaps you can tell from them. That was my conclusion, yes. > 2. With CVS, merge conflicts are easy to handle -- just edit the file, > look for the <<< and >>> that indicate conflicts, and fix up each one. > Can I do it that way in Git? Yes, you can. The files with conflicts has the same merge-conflict markers that you are used to. When you edit a file with merge-conflict markers, the development version (Emacs 25.0.50) should automatically enter the smerge-mode, which is a minor mode with support for that (see its documentation for a few useful commands). Furthermore, for each file you save after fixing all the conflicts, VC should automatically invoke Git with the "git add" command, so that the de-conflicted file being saved is ready to be committed. Once you fix all the conflicts, invoke "git commit" to complete the merge (which "git pull" normally does automatically, but didn't do due to the conflicts). After that, you should "git push" to update the repository on Savannah with your local commits. I think this is very similar to what you used to do with CVS and bzr, the only difference is that a singe commit command after fixing the conflicts is replaced with 2 separate commands: first commit locally, then push upstream.