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: VC mode and git Date: Sun, 05 Apr 2015 17:31:53 +0900 Message-ID: <87mw2nf01y.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83twx2xoc8.fsf@gnu.org> <87619hke3u.fsf@uwakimon.sk.tsukuba.ac.jp> <551A3F17.6020903@math.ntnu.no> <20150331085055.GA2871@acm.fritz.box> <87zj6tiko1.fsf@uwakimon.sk.tsukuba.ac.jp> <20150331104935.GB2871@acm.fritz.box> <87y4mdi7tj.fsf@uwakimon.sk.tsukuba.ac.jp> <20150331214347.GH2871@acm.fritz.box> <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> <87vbhbft9a.fsf@uwakimon.sk.tsukuba.ac.jp> <83619bnjsy.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 1428222733 3638 80.91.229.3 (5 Apr 2015 08:32:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Apr 2015 08:32:13 +0000 (UTC) Cc: sorganov@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 05 10:32:06 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 1YefyP-0002oD-4X for ged-emacs-devel@m.gmane.org; Sun, 05 Apr 2015 10:32:05 +0200 Original-Received: from localhost ([::1]:35537 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YefyO-0007Ba-7e for ged-emacs-devel@m.gmane.org; Sun, 05 Apr 2015 04:32:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55100) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YefyK-0007BE-Vp for emacs-devel@gnu.org; Sun, 05 Apr 2015 04:32:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YefyJ-0006Ui-MU for emacs-devel@gnu.org; Sun, 05 Apr 2015 04:32:00 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:53281) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YefyF-0006UD-Oa; Sun, 05 Apr 2015 04:31:56 -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 85A211C3830; Sun, 5 Apr 2015 17:31:53 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 6971B120EC9; Sun, 5 Apr 2015 17:31:53 +0900 (JST) In-Reply-To: <83619bnjsy.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:184903 Archived-At: Eli Zaretskii writes: > > From: "Stephen J. Turnbull" > > I've been through that too, I tried to reproduce and failed. My > > understanding was that Richard had edited and had uncommitted changes > > *before* "the" pull. > > I'm not sure this is what happened; I think he had _committed_ changes > that conflicted. No, I am sure that at some point he pulled when fully committed, from trying the experiments. > Let's reiterate what Richard described in his original message: Thank you for the courtesy. > I committed some changes using C-x v v in vc-dir. > Something went wrong with lisp/ChangeLog. > > It appears that my change log entries went into an old version of that > file; I don't know why this happened, since I wrote them today after > doing 'git pull'. OK, so I interpreted this as 1. Hack the "some changes" mentioned above. 2. Git pull successfully, implying the files changed in Richard's workspace but (I assume) not committed did not conflict. 3. Edit ChangeLog and C-x v v to commit, successfully. But some log messages were missing. (This makes no sense to me, unless somehow he did not see messages that said that the merge was not performed. Is it possible that vc displays messages from stdout but not stderr or something like that? I'm grasping at straws, I know -- but Richard is a good bug reporter, and yet what he reports doesn't make sense.) > After this, I did 'git pull' again, and it said there was a merge > conflict in lisp/ChangeLpg. A lot of text appears to be missing from > the file. It said, "fix conflicts and then commit the result." If the previous pull succeeded, does this mean that he lost a race in a handful of minutes? And lost "a lot" of text? Weird. > I edited lisp/ChangeLog and tried to commit it with C-x v v. > That gave me the error message > > fatal: cannot do a partial commit during a merge. Confirmation that there were uncommitted files throughout. But wait! the plot thickens: > I am now stuck. I don't know what a "merge" is; it is certainly > nothing I asked to do. > > Note the "merge conflict" part and the error message Richard cites: > "fix conflicts and then commit the result." This is a message > displayed by Git when you have a conflict in _committed_ changes, and > the merge fails half-way through. Error messages about conflicts in > uncommitted changes are different > > The second error message, viz.: > > fatal: cannot do a partial commit during a merge. > > is because "C-x v v" invokes "git commit --only lisp/ChangeLog", which > AFAIR always fails in this situation, for the reason hinted by the > error message. Aha! But "git commit --include lisp/ChangeLog" DTRTs in this case, committing the staged changes from the files successfully merged as well as the new changes from the files where conflicts were resolved. (Tested in a toy repo.) In other words, *Emacs* screwed Richard, not git. git, with a little scripting (either in the shell or in vc.el) may very well be quite capable of supporting Richard's (and Alan's!) preferred "leave the changes still being tested uncommitted" workflow. > Yes, something like that. In fact, I think the root cause of the > original problem was that "C-x v v", which tried to commit a single > file in the middle of a merge. Instead, the correct action is either > 'v' from vc-dir or "git commit" from the shell prompt. I don't think "git commit" will actually work. "git commit" alone will either commit only the unconflicted staged files (I think this unlikely) or will refuse to commit because it remembers that ChangeLog was conflicted (more likely). You need to "git add lisp/ChangeLog", or you use --include on the command line (note that in this situation "git commit lisp/ChangeLog" and "git commit --only lisp/ChangeLog" are equivalent according to the manual). Perhaps v in vc-dir might do the right thing, but I suspect it suffers from the same issue as "git commit" with no file arguments. > It would be good if "C-x v v" tried to support this situation > better. Definitely. Unfortunately it's late and I can't guess whether "--include" is generally appropriate, or whether there's a more frequent case where "--only" is appropriate, and "--only" should get precedence. I hope Eric knows.