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: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs Date: Thu, 28 May 2015 18:26:19 +0300 Message-ID: <831ti0yb8k.fsf@gnu.org> References: <20150527165006.32357.80915@vcs.savannah.gnu.org> <87egm13yrm.fsf@gmx.de> <838uc8yd3c.fsf@gnu.org> <87617c3fq3.fsf@gmx.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1432826891 27593 80.91.229.3 (28 May 2015 15:28:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 May 2015 15:28:11 +0000 (UTC) Cc: bruce.connor.am@gmail.com, emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 28 17:27: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 1Yxziw-0002Fb-QH for ged-emacs-devel@m.gmane.org; Thu, 28 May 2015 17:27:58 +0200 Original-Received: from localhost ([::1]:59593 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yxziw-00068G-7K for ged-emacs-devel@m.gmane.org; Thu, 28 May 2015 11:27:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60182) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yxzij-00067x-6o for emacs-devel@gnu.org; Thu, 28 May 2015 11:27:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yxzif-0000Hl-PC for emacs-devel@gnu.org; Thu, 28 May 2015 11:27:45 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:37148) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yxzif-0000Hc-Cu for emacs-devel@gnu.org; Thu, 28 May 2015 11:27:41 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NP200L00FV8AH00@mtaout27.012.net.il> for emacs-devel@gnu.org; Thu, 28 May 2015 18:21:39 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NP200DA5G03OH80@mtaout27.012.net.il>; Thu, 28 May 2015 18:21:39 +0300 (IDT) In-reply-to: <87617c3fq3.fsf@gmx.de> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.183 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:186911 Archived-At: > From: Michael Albinus > Cc: bruce.connor.am@gmail.com, emacs-devel@gnu.org > Date: Thu, 28 May 2015 17:05:08 +0200 > > Eli Zaretskii writes: > > >> As a general tip. Next time you try to pull and find out someone > >> already has already done what you just did, don't resolve the merge > >> conflict. Instead, abort the merge with `git merge --abort` (this will > >> get you back to the state you had right before the pull), and then > >> locally revert your commit. > > > > I don't see how this advice will be able to keep Michael out of > > trouble next time. AFAICT, it will just get him in a different > > situation, one that isn't simpler or safer to deal with. Locally > > reverting commits risks losing them, for example. > > That's what I did, likely. > > However, the tip might give me a way to bring the git repo back to a > stable state, with potential loosing of local changes. As long as I'm > not fluent in solving merge conflicts, that's good to know. IMO, that's a misconception. There's nothing "unstable" in having conflicts or having a merge initiated by "git pull" be aborted due to conflicts. You can make safe changes from this situation, and you can make unsafe changes from a reset tip (as it seems you did). The procedure to resolve merge conflicts is simple: edit the conflicted files, run "git add" on each one of them (VC should do this automatically), make sure "git status" shows only staged files, and then "git commit" all of them. That's it. And at any stage, you can always use "git status" and "git diff origin/master" to show what still needs to be done to bring your local clone in sync with upstream. > > OTOH, merge conflicts are nothing to be afraid of, the procedure to > > handle them is simple and straightforward. Michael (and every one > > else here) should IMO master that simple procedure, instead of > > avoiding it. > > > > In a dVCS, you cannot rely on being able to avoid merges all the time > > anyway. There are always races with other developers. > > If git would be more friendly to tell what happens ... It will be more helpful if you use "git status" more frequently. > why the hell I must take care on files I've never touched myself. You don't. You just need to commit them after all conflicts have been resolved.