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: Sun, 05 Apr 2015 15:28:03 +0300 Message-ID: <83y4m6n4j0.fsf@gnu.org> 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> <551FA115.5090400@gmx.at> <834mowp7cj.fsf@gnu.org> <55200A71.9040902@gmx.at> <83oan3onki.fsf@gnu.org> <87sicffqma.fsf@uwakimon.sk.tsukuba.ac.jp> <834movnjm0.fsf@gnu.org> <87lhi7ezge.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1428236904 10591 80.91.229.3 (5 Apr 2015 12:28:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Apr 2015 12:28:24 +0000 (UTC) Cc: rudalics@gmx.at, sorganov@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 05 14:28:15 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 1Yejew-0008P5-Gi for ged-emacs-devel@m.gmane.org; Sun, 05 Apr 2015 14:28:14 +0200 Original-Received: from localhost ([::1]:36218 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yejev-0000iD-JD for ged-emacs-devel@m.gmane.org; Sun, 05 Apr 2015 08:28:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yejer-0000hx-BS for emacs-devel@gnu.org; Sun, 05 Apr 2015 08:28:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yejem-0003be-Is for emacs-devel@gnu.org; Sun, 05 Apr 2015 08:28:09 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:34142) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yejem-0003bV-65; Sun, 05 Apr 2015 08:28:04 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NMC00K0027Q5K00@mtaout29.012.net.il>; Sun, 05 Apr 2015 15:25:34 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMC00IHR2IMVH20@mtaout29.012.net.il>; Sun, 05 Apr 2015 15:25:34 +0300 (IDT) In-reply-to: <87lhi7ezge.fsf@uwakimon.sk.tsukuba.ac.jp> 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.185 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:184915 Archived-At: > From: "Stephen J. Turnbull" > Cc: Richard Stallman , > rudalics@gmx.at, > sorganov@gmail.com, > emacs-devel@gnu.org > Date: Sun, 05 Apr 2015 17:44:49 +0900 > > Eli Zaretskii writes: > > > > If the uncommitted files were inadvertant (typical beginner > > > mistake), your advice to commit, pull again, and fix the conflicts > > > is appropriate. But this doesn't work for Richard, who deliberately > > > leaves some changes uncommitted. > > > > Why doesn't it work? Because changes he didn't want to commit just > > yet will end up committed? I think this is a small price to pay for > > avoiding to learn about stashing, and for having what is mostly the > > same workflow he and others had with CVS. > > Richard will speak for himself about the size of the price, but I > suspect he doesn't need to pay it at all in the current case (see my > other post, specifically about "git commit --include" Maybe I'm missing something, but I don't understand how --include could have helped in this case. The man page says: --include Before making a commit out of staged contents so far, stage the contents of paths given on the command line as well. So AFAIU "git commit --include FILE" is equivalent to these two commands: git add FILE git commit If this is true, then this will commit both the file with conflicting uncommitted changes and the rest of the stuff fetched from upstream. So how is it different from what I described on the Wiki? The result is the same: the changes that were left uncommitted because they are "not ready" will end up committed. My procedure is IMO better in that it doesn't require any non-default switches to commands. > He will need to do something else in the case that he runs into the > "will overwrite your changes" message. But that's exactly the situation I thought we were discussing: uncommitted changes that conflict with changes upstream. So now I'm confused about the use case you referred to above. > However, since he seems comfortable with the "don't touch ChangeLogs > until after you pull" workflow, I'm guessing the probability that > he'll run into something really ugly is unlikely. Agreed, and that's why I think stash could be avoided.