From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Steinar Bang Newsgroups: gmane.emacs.devel Subject: Re: VC mode and git Date: Sun, 05 Apr 2015 00:05:27 +0200 Organization: Probably a good idea Message-ID: <867ftr8s7s.fsf@dod.no> References: <83twx2xoc8.fsf@gnu.org> <20150401103225.GA2633@acm.fritz.box> <87h9t080gx.fsf@javad.com> <83384jsx3o.fsf@gnu.org> <83pp7nrfdn.fsf@gnu.org> <83a8yqr226.fsf@gnu.org> <831tk2qvz5.fsf@gnu.org> <87384ii26v.fsf@uwakimon.sk.tsukuba.ac.jp> <83wq1tptvp.fsf@gnu.org> <87pp7lhc9h.fsf@uwakimon.sk.tsukuba.ac.jp> <83sichpqe9.fsf@gnu.org> <87ioddglu6.fsf@uwakimon.sk.tsukuba.ac.jp> <83a8yoq56m.fsf@gnu.org> <87384ghm1a.fsf@uwakimon.sk.tsukuba.ac.jp> <837ftspcis.fsf@gnu.org> <551FA115.5090400@gmx.at> <834mowp7cj.fsf@gnu.org> <55200A71.9040902@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1428185158 8134 80.91.229.3 (4 Apr 2015 22:05:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Apr 2015 22:05:58 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 05 00:05:49 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 1YeWCJ-0008TR-Hy for ged-emacs-devel@m.gmane.org; Sun, 05 Apr 2015 00:05:47 +0200 Original-Received: from localhost ([::1]:34466 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YeWCI-0000A7-R2 for ged-emacs-devel@m.gmane.org; Sat, 04 Apr 2015 18:05:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35615) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YeWBr-00009z-CS for emacs-devel@gnu.org; Sat, 04 Apr 2015 18:05:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YeWBo-0004k1-4w for emacs-devel@gnu.org; Sat, 04 Apr 2015 18:05:19 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:35703) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YeWBn-0004jX-Tz for emacs-devel@gnu.org; Sat, 04 Apr 2015 18:05:16 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YeWBj-00083n-3u for emacs-devel@gnu.org; Sun, 05 Apr 2015 00:05:11 +0200 Original-Received: from cm-84.208.248.210.getinternet.no ([84.208.248.210]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 05 Apr 2015 00:05:11 +0200 Original-Received: from sb by cm-84.208.248.210.getinternet.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 05 Apr 2015 00:05:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 91 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cm-84.208.248.210.getinternet.no Mail-Copies-To: never User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (windows-nt) Cancel-Lock: sha1:3pgIwcWJkfQBbD5vhfUasEBy7FI= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:184888 Archived-At: >>>>> martin rudalics : > error: Your local changes to the following files would be overwritten by merge: > ... > Please, commit your changes or stash them before you can merge. > Aborting > AFAICT this signlas a succeeding fetch and a failing merge. Not exactly, it signals a succeding fetch, and no merge done > IIUC git's pull is not atomic. When the merge fails with a message like > the above I have no idea in what state my copy of a repository is in. It is in the same state it was as before you did the pull. > Well, I wouldn't know even without that message ... [snip!] > In the one case I get the message cited above. In the other case I get > conflicts and git asks me to resolve them. Now, _if_ you have modified uncommitted changes, _and_ get conflicts, then things get slightly worse. The conflicts will not be in any of your locally modified files, because those haven't been touched by the merge (if they were, the merge wouldn't have started). > Now suppose that, in reaction to the message above I do > git commit -a > git pull > and now am told to resolve my conflicts. I do that via smerge-mode, > save the file(s) which had the conflict(s) and do > git commit > as recommended. I tried that just now with a conflict in Changelog. > After this git told me that > On branch master > Your branch and 'origin/master' have diverged, > and have 2 and 74 different commits each, respectively. > (use "git pull" to merge the remote branch into yours) > All conflicts fixed but you are still merging. > (use "git commit" to conclude merge) This message means your merge wasn't completed. What did git commit say? Were there more files than the ChangeLog that needed merging? Didn't smerge-mode automatically stage the conflict-fixed file for commit? (didn't you remove all conflict markers?) > and, after the recommended git pull > CONFLICT (content): Merge conflict in lisp/ChangeLog > Automatic merge failed; fix conflicts and then commit the result. > just that I did not find any conflicts at this stage. You mean no conflict markers in the ChangeLog? Did you try diffing ChangeLog against orgin/master to see if there were changes and if they looked sensible? Did you try staging ChangeLog manually for commit? git add ChangeLog > So I practically ended up in an infinite loop which I was able to > break only via a hard reset. I suppose this is similar if not identic > to Richard's original problem which is apparently very easily > reproducible here. A hard reset sounded a bit drastic. Did you have changes in the ChangeLog that were yours? Or was the conflict purely caused by git? > Stashing is offered in the first git message cited above. If it's bad > we should tell people why. OTOH I never had a problem with stashing > and in particular it never got me into the loop I mentioned later. The reason to stay away from stash from this workflow, is that it is yet another concept to relate to. The fact that "git stash pop" can result in a conflict that needs to be resolved and seemingly needs to be committed (it doesn't), is a complicating factor for a simple CVS-like workflow.